Question

Forgive me if this has been asked before; I did a search but couldn’t find anything that specifically answered this question, but I’d be happy to be referred.

I’m taking a peek at both the Entity Framework and LINQ to SQL, and while I like the systems (and of course the LINQ integration) I’m a little skeptical on the data-binding aspect. I’ve taken query results and inspected them, and they don’t appear to implement the standard .NET list-binding interfaces (IBindingList, and more importantly ITypedList), leading me to believe that binding them to a grid (or anything else) is going to use reflection to get/set my entity properties. This seems like a comparatively expensive operation, especially when all of the code is generated anyway and could implement the interfaces.

Does anyone have any insight into this? Is reflection used to get/set the value of the properties? If yes, does this have a performance impact that’s noticeable, and does anyone have any idea why they went this route?

Edit

I’m actually concentrating on whether or not ITypedList is implemented somewhere along the way, as that’s what has the capability to provide an explicit mechanism for defining and interacting with properties without resorting to reflection. While I didn’t have a LINQ to SQL project up, I did inspect a simple Entity Framework entity query result, and it did not appear to implement ITypedList. Does anyone know if I’m just looking at something incorrectly, or if not why this is the case?

Edit 2

After accepting Marc’s answer, I thought it might be helpful for others if I posted some simple code I used to seamlessly implement his solution. I put the following in the static constructor for my class:

public static ContextName()
{
    foreach(Type type in System.Reflection.Assembly.GetExecutingAssembly()
        .GetTypes())
    {
        if (type.GetCustomAttributes(typeof(System.Data.Linq.Mapping
            .TableAttribute), true) != null)
        {
            System.ComponentModel.TypeDescriptor.AddProvider(
                new Hyper.ComponentModel.HyperTypeDescriptionProvider(
                    System.ComponentModel.TypeDescriptor.GetProvider(
                        type)), 
                type);
        }
    }
}

While this is for LINQ to SQL, I’m sure an equivalent version could be written for the Entity Framework. This will scan the assembly for any types with the Table attribute and add a custom provider for each of them.

Answer 1

The Expression API that underpins LINQ etc is founded on reflection (MemberInfo), not the component-model (PropertyDescriptor etc) – so there is not a huge requirement for ITypedList. Instead, the contents are inferred from the T in IQueryable<T>, IEnumerable<T> and IList<T> etc.

The closest you might get is IListSource, but that will still just be a shallow wrapper around a proper typed list.

If performance of runtime binding (to PropertyDescriptor) is key, you might want to look at HyperDescriptor – which uses Reflection.Emit and TypeDescriptionProvider to wrap the component-model.

Re the “why” etc; note that in almost all cases with LINQ-to-SQL and EF the Expression (or the “create and set members” part) is going to be compiled to a delegate before it is invoked – so at runtime there is no huge reflection cost. And likewise, with LINQ-to-Objects everything is already compiled (by the C# compiler).