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:
More to follow…