Never SELECT * from Entity Framework called Stored Procedures

The Entity Framework can help us create an efficient Data Access Layer or a horribly inefficient one. 

It's worth mentioning that if we use Entity Framework to call a stored procedure that returns a database derived Entity using a SELECT * (star), we will have that horribly inefficient DAL.  Of course, as we've been told for years, SELECT * is 99.0% wrong with 1% for those dynamic field cases.  With EF calling a stored procedure, it's really wrong.

SQL Profiler will show us that the store procedure does return all records as fast as it can, barring a badly written stored procedure or low SQL server memory.  Entity Framework unfortunately does not assume all fields have returned.  EF then calls back with the defined primary key for each record.  This means that for a stored procedure that returns 1 million rows in one connection, actually returns 2 million rows with 2 million and one database server calls / connections from the application layer.  Try it on a 3 record table sometime to see that it calls SQL Server 4 times for three rows even when we use a stored procedure.  Enterprise DBA's will complain as they should.  If there is an obscure switch to avoid this, I couldn't find it.

The Moral of the Story:

• Always define fields from the SELECT statement even if SQL 2005 and greater does optimize it for us.
• Use SQL Profiler to look at the number of calls and the I/O count of each call.

Containing Silverlight Lists and DataGrids in the Browser Window

1. Remove the ScrollViewer from the page if it exists.
2. Contain all upper area graphics and edit controls in a RowDefinitions of explicit size or Auto.
3. Contain the lower List(s) in a final Grid RowDefinition with the Star notation to fill the remainder of the window using the outer-most Grid as a parent container.
4. Optionally specify for the List properties,  VerticalAlignment="Top" and VerticalContentAlignment="Stretch".  Otherwise the List and its borders will stretch to the bottom of the screen even if it has no items.  Either way may be preferred. 

Runtime:

Designer:

XAML:

Code-Behind:

private void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    listBox1.Items.Clear();
    listBox2.Items.Clear();

    for (int i = 1; i <= 100; i++)
    {
        string listItem = "List Item " + i.ToString();

        listBox1.Items.Add(listItem);
        listBox2.Items.Add(listItem);
    }
}