实体框架/LINQ to SQL数据绑定是否使用反射? [英] Does Entity Framework/LINQ to SQL Data Binding use reflection?
问题描述
请问我以前是否曾问过这个问题?我进行了搜索，但找不到能具体回答此问题的任何内容，但很高兴能被推荐.
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.
我正在查看实体框架和LINQ to SQL，虽然我喜欢系统(当然还有LINQ集成)，但我对数据绑定方面还是有些怀疑.我已经获取了查询结果并对其进行了检查，它们似乎没有实现标准的.NET列表绑定接口(IBindingList，更重要的是ITypedList)，使我相信将它们绑定到网格(或其他任何东西)将使用反射来获取/设置我的实体属性.这似乎是一个相对昂贵的操作，尤其是当所有代码都已生成并且可以实现接口时.
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?
修改
我实际上是在集中注意ITypedList是否在实现过程中的某个地方实现，因为它具有提供明确的机制来定义和与属性交互的能力，而无需借助反射.虽然我还没有LINQ to SQL项目，但我确实检查了一个简单的Entity Framework实体查询结果，但它似乎没有实现ITypedList.有谁知道我只是看错了东西，还是不知道为什么?
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?
编辑2
接受Marc的回答后，我认为如果发布一些我用来无缝实现他的解决方案的简单代码，对其他人可能会有帮助.我将以下内容放入类的静态构造函数中:
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);
}
}
}
虽然这是针对LINQ to SQL的，但我确定可以为实体框架编写等效的版本.这将扫描具有Table属性的任何类型的程序集，并为每个类型添加一个自定义提供程序.
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.
推荐答案
支持LINQ等的Expression API是基于反射(MemberInfo)而不是组件模型(PropertyDescriptor等)的，因此没有ITypedList的巨大需求.而是从IQueryable<T>，IEnumerable<T>和IList<T>等中的T推断内容.
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.
您可能会得到的最接近的是IListSource，但这仍然只是适当的类型列表的浅层包装.
The closest you might get is IListSource, but that will still just be a shallow wrapper around a proper typed list.
如果运行时绑定(到PropertyDescriptor)的性能很关键，则可能需要查看
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.
重新输入为什么"等；请注意，在使用LINQ-to-SQL和EF的几乎所有情况下，Expression(或创建和设置成员"部分)在被调用之前都将被编译成委托-因此在运行时不会有巨大的反映.成本.同样，使用LINQ-to-Objects，所有内容都已经通过C#编译器进行了编译.
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).
这篇关于实体框架/LINQ to SQL数据绑定是否使用反射?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
