EntityDataSource's flattening of complex type properties

divega — Sat, 24 May 2008 20:11:40 GMT

I explained a few days ago the rules of wrapping in this blog post. But why do we wrap after all?

Julie asked for some details today in the forums. I think the answer is worth of a blog post.

In ASP.NET there are different ways of specifying which property a databound control binds to: Eval() Bind(), BoundField.DataField, ListControl.DataTextField, etc. In general, they behave differently.

The flattening we did on EntityDataSource is an attempt to make the properties that are exposed by EDM entities available for 2-way databinding in most of those cases.

For instance, for a customer that has a complex property of type Address, we provide a property descriptor for customer.Address, and also for customer.Address.Street, customer.Address.Number, etc.

At runtime, in the case of a control binding to Eval(“Address.Street”) from a customer, Eval will use the property descriptor corresponding to Address, and it will drill down on it to extract the value of the Street property on it.

A grid column of a BoundField derived type with DataField = “Address.Street” will work differently: it will just look for a property descriptor in the data item with a name as “Address.Street”. In fact, EntityDataSource is the first DataSource control that I know off that will provide such a thing.

Bind(“Address.Street”) will work in a similar fashion to Eval() when reading the properties into the data bound control, but will act a little bit more like BoundField when sending back changes to the DataSource.

There are a few cases in which the behavior is not any of the above and hence you end up with a control that cannot have access to a complex type’s properties. You can expect us to work closely with the ASP.NET team in making the experience smoother in future versions. But for the time being, what you can do is create an explicit projection of the properties. For instance, in Entity SQL:

SELECT c.ContactId, c.Address.Street AS Street
FROM Northwind.Customers AS c

I think it is worthy of mentioning:

Remember flattening of complex properties only happen under certain conditions (see wrapping).
We worked very closely with the ASP.NET Dynamic Data in this release, to enable their technology to work EDM through the EntityDataSource. I think it is very worthy of trying.

Hope this helps.

EntityDataSource: To wrap or not to wrap

divega — Tue, 13 May 2008 21:08:00 GMT

Note: Somehow the <TEntity> generic argument had disappeared from the extension method definition. I am fixing it today after several months. Sorry for the inconvenience!

Fresh from the forums today: A customer asks how to get the real entity object in the RowDataBound event of a GridView.

We made some complex design decisions during the development of the EntityDataSource, and I guess that will give us plenty of material for blogging :)

With the EntityDataSource, we faced the interesting problem of building a bridge between the existing ASP.NET databinding infrastructure and the world of EDM. One of the techniques we use to solve the problem is wrapping entities in smart databinding objects. As Colin explains it in his answer posted to the forums:

Why are you seeing a wrapper instead of the entity? Some of the unique features of the Entity Data Model prevent us from directly binding the entity. For instance, when inserting a Product I also need to insert a relationship to a Category. The wrapper adds the relationship to the entity, basically as a foreign key value.

The wrapper object implements the ICustomTypeDescriptor interface, which makes it work well with databinding, but when you try to get your original entity object, for instance form the arguments of the RowDataBound, you will get a wrapper object instead of the entity object you are expecting.

I don't want to make things much more complicated than they need to be, but I think the generic solution may be useful for some customers.

First of all, here are the rules for wrapping:

The wrapping mechanism only takes place if you initialize your EntityDataSource using EntitySetName.
When you instead set CommandText to a query that returns entities (i.e. "SELECT VALUE c FROM Northwind.Customers AS c", then you get normal entities.
When you instead set CommandText to a query that returns a projection of properties (i.e. "SELECT c.CustomerID, c.CustomerName FROM Northwind.Customers AS c"), then you get a DbDataRecord.
Finally, if you set the Select property to do a projection (i.e. "it.CustomerID, it.CustomerName", you get DbDataRecord regardless of how you start your query.

If you use the RowDataBound event very often in your code, then, I would suggest having around some code similar to this (thanks David for coming up with this code first):

static class EntityDataSourceExtensions

{

public static TEntity GetItemObject<TEntity>(object dataItem)

where TEntity : class

{

var entity = dataItem as TEntity;

if (entity != null)

{

return entity;

}

var td = dataItem as ICustomTypeDescriptor;

if (td != null)

{

return (TEntity)td.GetPropertyOwner(null);

}

return null;

}

And this is the usage:

protected void GridView_RowDataBound(object sender, GridViewRowEventArgs e)

{

var entity = EntityDataSourceExtensions.GetItemObject<Product>(e.Row.DataItem);

//...

}

I hope this will help some.

Diego Vega : Entity Framework Databinding

EntityDataSource's flattening of complex type properties

EntityDataSource: To wrap or not to wrap