I’ve been thinking about the EntityDataSource that has been mentioned in the forums. It is something that is going to be added to Entity Framework by RTM, but it doesn’t exist in current bits for us to experiment with.

The reason I’ve been thinking about it is because of some of the issues/confusion with the LINQDataSource and I’m really hoping that the EF team will be looking at that, learning from it, and making sure that some of those problems don’t exist in the new component.

Most of the issues with the LINQDataSource are a result of very realistic limitations. But where I see the problem is just the difficulty many users have using it because they don’t understand what’s going on underneath and to work within the limitations, there are some very non-intuitive things they need to do.

I wrote a bunch of LINQDataSource demos for a presentation and spent a lot of time learning workarounds in order to achieve some very common scenarios although not quite as common as the typical demos. That’s where I hope EntityDataSource makes it easier. I don’t want to have to work so hard to discover how to make it work.

Here’s an example of a something I think is a common scenario.

I have an Entity for SalesOrderHeaders from AdventureWorksLT.

I would like to have an editable gridview of these records.

I’d like to display the customer name in the grid not the customer ID.

Not too strange, right?

But there are a lot of issues encountered along the path to create this solution.

1)One of the most often asked questions about the LINQDataSource is “why can’t I edit?”. The answer is most often because the developer selected the fields they wanted displayed in the grid and a huge number of people don’t realize that they are creating an anonymous type by doing this. Yes there are some clues. The “advanced’ button goes away. There’s no “enable delete” etc. checkboxes on eh Task menu.

A better way? It would be much easier if the wizard started out by asking if you have any intention of editing and if the answer was yes, does NOT present the end user with the option to select fields.

An even better way? I know the model won’t allow this but it would be great to have another entity definition (subset of the properties) for this entity without creating an EntityKey conflict.

2) This also means that I can’t really take touch the CustomerName in the EntityRef (SalesOrderHeaders.Customer)unless I create an anonymous type, which I don’t want to do. So the next obvious solution is to create a LINQDataSource for the Customers and format the CustomerID column in my gridview to be a template field with a dependency on the CustomerLINQDataSource.

         <asp:templatefield HeaderText=”CustomerID” SortExpression=”CustomerID”>
                    <edititemtemplate>
                        <asp:DropDownList ID=”DropDownList1″ runat=”server”
                            DataSourceID=”LinqDataSource2″ DataTextField=”CompanyName”
                            DataValueField=”CustomerID” SelectedValue='<%# Bind(“CustomerID”) %>’>
                        </asp:DropDownList>
                    </edititemtemplate>
                    <itemtemplate>
                        <asp:Label ID=”Label1″ runat=”server” Text='<%# Eval(“Customer.CompanyName”) %>’></asp:Label>
                    </itemtemplate>
                </asp:templatefield>

But this creates yet another problem that I may not have any awareness of. The default deferred loading will cause an extra round trip to the database for each SalesOrderHeader record to get the CustomerName.

A better way? Give us a Deferred Loading or Eager Loading option in the wizard!

3) There is a really weird gotcha because we are using EntityRefs for the CustomerID/CustomerName DropDown. Editing doesn’t work properly unless you set the LINQDataSource property to StoreOriginalValuesinViewState to False. It’s logical but again, totally non-intuitive. If you don’t do it, you will get this error message:
“System.InvalidOperationException: Could not find a row that matches the given keys in the original values stored in ViewState.  Ensure that the ‘keys’ dictionary contains unique key values that correspond to a row returned from the previous Select operation.” That’s scary, huh? It took some googling to figure this one out.

A better way? If the LINQDataSource could trap this exception and give some better guidance about what the problem is and how to deal with it. Or something…

These are some of the things I spent a ridiculous amount of time on in order to get this scenario working. And seems like nothing compared to what Roger Jennings banged his head on!

It would be great not to have to go through this again with the ObjectDataSource, if it’s possible to make some of these issues easier to deal with!

A few weeks ago, I was mooning over Extension Methods. Somehow, in the collection of language enhancements to VB9 and C#3, they have become a bit of a sleeper feature in light of LINQ. Everything is though, right?

So I wrote about them and thought about them, but then went back to my task at hand.

Danny Simmons also recently started seeing the light about Extension MEthods. But instead of going back to what he was doing, he spent quite a bit of time playing with them and is now blogging an Entity Framework Extension Method Extravaganza!

He’s going crazy with it already. What fun!

• EF Extension Method Extravaganza Part I – ObjectStateEntry
• EF Extension Methods Extravaganza part II – Relationship Entry & IRelatedEnd
• EF Extension Methods Extravaganza Part III – Fun with LINQ to Objects