The case against EntityDataSource

Why does Microsoft insist on developing the EntityDataSource? I really don’t see the benefit. It’s just adding bloat to Entity Framework, especially since most people are moving away from Web Forms in favor of MVC. It was never even a good idea in the first place. It’s supposed to make data binding easier, but it ends up causing many problems.

It’s difficult to debug

It works great when it works, but when it doesn’t work… Ugh. When it breaks, it’s nearly impossible to determine the problem without blindly Googling around and trying things until they work, which is terrible. I once had to use SQL Server Profiler to monitor queries to determine the sql it had generated so I could properly debug the issue.

You also can’t see the results being returned without viewing the output on the page. Manually binding allows you to view the IEnumerable returned and manipulate the results further, if necessary.

It forces data access logic in your views

If you want a list of all Users in your database then great, add an EDS and grab all of them. But what if you need to filter them? Forget about it. You have to add a Where property and manually write SQL yourself. Or use the <WhereParameters> property with a bunch of verbose filters:

<WhereParameters>
    <asp:SessionParameter Name="Id" DbType="Int32" SessionField="Id" />
    <asp:SessionParameter Name="Name" DbType="String" SessionField="Name" />
    <asp:ControlParameter ControlID="txtCompany" DbType="String" DefaultValue="" Name="Company" 
        PropertyName="Company" />
</WhereParameters>

It’s a mess of text and it’s impossible to determine what you’re actually selecting. Compared to:

context.Tests.Where(t => t.Id = (int)Session["Id"] 
                         && t.Name = (string)Session["Name"] 
                         && t.Company = txtCompany.Text);

Much cleaner and much more readable.

This also forces data access to live in your views which is a violation of Separation of Concerns. Data access should live where it belongs – in the aptly named Data Access Layer.

It’s slow

As a quick example, I set up a page with an EntityDataSource selecting all columns from a table with 50,000 rows and putting them into a GridView. To compare, I also manually binded the GridView by selecting from the ObjectContext itself.

Here’s a sample of the code for the EDS:

 <asp:EntityDataSource runat="server" ID="eds" ConnectionString="name=Test" 
     AutoGenerateWhereClause="True" DefaultContainerName="Test" 
     EntitySetName="Test" AutoSort="true" />
 <asp:GridView runat="server" ID="gvEds" DataSourceID="eds" AllowPaging="True"></asp:GridView>

And the manual binding:

<asp:GridView runat="server" ID="gvNoEds" AllowPaging="true" PageSize="50"></asp:GridView>

var tests = context.Test.ToList();
gvNoEds.DataSource = tests;
gvNoEds.DataBind();

Results:

Kill it with fire

I’m really not sure why Microsoft insists on continuously supporting EntityDataSource. I see a slow, outdated control helper that abstracts too much while adding a lot of complexity. Let it die.