As it was announced today, the EntityDataSource is now part of Entity Framework, and a first beta version of it is available in .NET 3.5 SP1 Beta 1 and Visual Studio SP1 Beta 1.
I have meant to answer Julie's post "Thinking about the EntityDataSource" for several months. But I always thought it was risky to talk about stuff that hadn't been released.
Now that customers can actually smell and touch it, it is about time:
Some history and acknowledgments
EntityDataSource was developed by a small subset of the Entity Framework Team in less than nine months, which is a short period for most software projects at Microsoft. It is amazing to see what this small team has produced.
But bringing it to its current state would have not been possible without the help of several members the ASP.NET team, who were always helpful and devoted their time and knowledge to the project. They helped us not only in making it suit the needs of “classic” ASP.NET developers, but also of ASP.NET Dynamic Data.
Why a new DataSource?
You may have already learned that LinqDataSource is an excellent alternative for displaying the results of any LINQ query (including LINQ to Entities) in ASP.NET, although, to update the database, you need a LINQ to SQL backend. Also, it is possible to write some code and get ObjectDataSource perform 2-way databinding against Entity Framework classes, but that dilutes one of the design goals for DataSources, that it should be possible to implement most common scenarios in a declarative only fashion.
Entity Framework includes a text based query language called EntitySQL, which in v1 is the only way to get access to the full query capabilities of EF. The language is very “composable”, which enables us to create queries using builder methods (similar to LINQ sequence operators, but text based). On the other side, DataSources as all ASP.NET controls can be initialized using string properties in markup.
It is easy to conclude that using EntitySQL, it should be possible to create a DataSource control that does 2-way databinding using only markup.
In fact, this simple markup produces a fully functional CRUD form for the Customers EntitySet:
<asp:DetailsView ID="CustomerDetailsView" runat="server" AllowPaging="True" AutoGenerateRows="True" DataKeyNames="CustomerID" DataSourceID="CustomersDataSource"> </asp:DetailsView> <asp:EntityDataSource ID="CustomersDataSource" runat="server" ConnectionString="name=NorthwindEntities" DefaultContainerName="NorthwindEntities" EnableDelete="True" EnableInsert="True" EnableUpdate="True" EntitySetName="Customers"> </asp:EntityDataSource>
More to follow...
Lots to read and download From the Data Programmability Team   SP1 Beta Download, what's new
What are the pros and cons of using LinqDataSource vs EntityDataSource ?
There are a few differences in capabilities, but basically, there are enough similarities that the decision should be based on which data access stack you are using:
- If you are using LINQ to SQL, use LinqDataSource
- If you are suing Entity Framework, use EntityDataSoruce
LinqDataSource can also address some read-only scenarios on anything that supports LINQ, including in-memory data and even Entity Framework, but as soon as you want to do updates, it only knows how to do it on LINQ to SQL.
The other alternative that I should mention is ObjectDataSource, which can work on top of either stack if you create a component that wraps your data access and provide methods for inserts, queries, updates and deletes.