Along with a few hundred other DevConnections attendees, I got a sneak peek of the EntityDatasSource control on Monday during Danny Simmons’ Entity Framework Architecture session.
I think I paid more attention to the control than what Danny was saying because I was desperate to see how it was set up.
Before digging in though, I also wanted to note that the UI of the EDM Designer looks really pretty. I noticed that the association lines/connectors looked different; the whole thing was cleaner looking (were the association names gone?) and the Entities have their own little representative icon now. I can’t wait to see this in more detail.
The EntityDataSource wizard identifies EntityConnections in the config file and offers those to as choices for building the data source from. Once that is selected, the EntityContainer is also identified, offering the list of EntitySets from the container to use for the data source.
Like the LINQDatasource, you have the option of selecting all of the properties at once or selecting specific properties which will perform projection. Like the LINQDataSource, if you project properties, then you won’t get a full type back and the data will not be updatable.
There was a drop down list below the one where you choose which EntitySet you want to work with but I don’t recall what it’s name was. Danny did not drop it down. All I can think of that might be there (hopeful) is derived types since they don’t have their own EntitySet.
Although I don’t remember seeing it during the session, Danny did say that you can choose to eager load related data in the same way that you can with the Include method. I don’t know how this is done or if it will impact updating, but I don’t know why it would.
Like the LinqDataSource, the EntityDataSource performs server side paging, and it does client side caching – of current AND original data. The original data is not stored as complete objects, but the minimal data necessary to reconstruct state when it’s time to update. Updates happen, like any other data source, one at a time. So you have to pick an item, edit it and update it.
I’ve got some of my own examples of using series of entities in web apps which are very different from this. My solution, however, is aimed at a different scenario. Where the EntityDataSource is more scalable because of the server side paging and the fact that it is not caching full objects, my solution allows the user to do a bunch of edits then save them all at once. I keep the objects in the client side cache (I know – horrors! – but it’s an option for a developer to choose) and a collection of original objects cached on the server, though it’s an application cache, not a session cache.
Seeing the EntityDataSource has already given me some ideas of taking my solution and making it more scalable without losing the benefit of the bulk editing.
I can’t wait to get my hands on the new bits!
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!