Perdóname si esto se ha preguntado antes; Hice una búsqueda, pero no pude encontrar nada que respondiera específicamente esta pregunta, pero estaría encantado de ser referido.¿La encuadernación de datos de Entity Framework/LINQ to SQL utiliza la reflexión?
Echo un vistazo a Entity Framework y LINQ to SQL, y si bien me gustan los sistemas (y por supuesto la integración LINQ) soy un poco escéptico con respecto al aspecto vinculante de datos. He tomado los resultados de las consultas y los he inspeccionado, y no parecen implementar las interfaces de enlace de listas .NET estándar (IBindingList
, y más importante aún, ITypedList
), lo que me lleva a creer que los vincula a una grilla (o cualquier otra cosa) va a usar la reflexión para obtener/establecer las propiedades de mi entidad. Esto parece una operación comparativamente costosa, especialmente cuando todo el código se genera de todos modos y podría implementar las interfaces.
¿Alguien tiene alguna idea de esto? ¿Se usa la reflexión para obtener/establecer el valor de las propiedades? En caso afirmativo, ¿tiene esto un impacto en el rendimiento que sea notable, y alguien tiene alguna idea de por qué tomaron esta ruta?
Editar
De hecho, me estoy concentrando en si es o no ITypedList
se implementa algún lugar del camino, ya que eso es lo que tiene la capacidad de proporcionar un mecanismo explícito para la definición e interactuar con propiedades sin tener que recurrir a la reflexión. Si bien no tenía un proyecto de LINQ to SQL, inspeccioné un resultado simple de consulta de entidad de Entity Framework y no pareció implementar ITypedList
. ¿Alguien sabe si estoy mirando algo incorrectamente o, si no, por qué es este el caso?
Editar 2
Después de aceptar la respuesta de Marc, pensé que podría ser útil para otras personas si he publicado un código simple que utiliza para implementar sin problemas su solución. Pongo el siguiente en el constructor estático para mi clase:
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);
}
}
}
Si bien esto es para LINQ a SQL, estoy seguro de una versión equivalente se podría escribir para el marco de la entidad. Esto escaneará el ensamblaje de cualquier tipo con el atributo Table
y agregará un proveedor personalizado para cada uno de ellos.
Marc, si su proyecto HyperDescriptor funciona como lo espero, eso proporcionará exactamente lo que necesito. Todavía me resulta un poco confuso el hecho de que Microsoft no haga uso de su propia infraestructura de enlace de datos y confíe en el TypeDescriptor predeterminado que devuelve ReflectPropertyDescriptors, pero bueno. Si esto funciona, no me importa mucho. –