¿Por qué LinqPad crea campos en lugar de propiedades?

Question

Hace poco tomé el proyecto de crear una herramienta para LinqPad que arrojaría los resultados de la consulta al formato CSV para usar la herramienta en bases de datos masivas para obtener resultados rápidos. Una cosa que quería de la herramienta es que pueda funcionar en Visual Studio y LinqPad. Por lo tanto, si estaba usando LinqtoSQL en VS2010, o LinqPad, podría volcar los resultados rápidamente a un archivo csv, y luego abrirlo en Excel para ver los resultados.

El mayor inconveniente en el proyecto provino de cómo LinqPad construye sus DataContexts y cómo Visual Studio construye sus DataContexts. La mejor información que pude encontrar sobre cómo lo hace LinqPad proviene del here. Básicamente, lo que encontré en mi proyecto fue que VS2010 crea propiedades para sus DataContexts, pero LinqPad crea Fields. Por lo tanto cuando se utiliza la reflexión:

LINQPad:

dataContextType.GetProperties() //returns 0 
dataContextType.GetFields() //returns the Fields from LinqPad created DataContext 

VS 2010 LinqToSql:

dataContextType.GetProperties() //returns the Properties from VS created DataContext 
dataContextType.GetFields() //returns 0 

Entonces, ¿por qué utiliza LINQPad campos en lugar de en sus propiedades DataContexts? ¿No hubiera sido más factible copiar el patrón de Visual Studio LinqToSQL?

actualización

Sobre la base de un comentario que decidí hacer la misma pregunta en el LinqPad forum también.

Answer 1

Esta es una buena pregunta. La razón principal por la que LINQPad utiliza los campos para mapear columnas es por el rendimiento cuando se construye el DataContext tipeado que respalda las consultas conectadas a la base de datos.

No estamos hablando de la velocidad de ejecución de las propiedades (en realidad hay muy poca sobrecarga al ejecutar accesos simples y el JIT incluso puede alinearlas). La sobrecarga es cuando se construye el DataContext escrito a través de Reflection.Emit. Un campo es simplemente eso: un elemento de metadatos, mientras que una propiedad requiere emitir una definición de campo, una definición de propiedad, dos métodos para los descriptores de acceso (cada uno con IL para obtener/establecer el campo subyacente). Debido a que los usuarios pueden señalar LINQPad a bases de datos con más de 1000 tablas y funciones, esto puede sumarse en términos del tiempo necesario para construir el ensamblaje, así como su tamaño (aumentando la actividad de HDD y el conjunto de trabajo).

Ha planteado un problema interesante en la falta de unificación entre PropertyInfo y FieldInfo en el modelo de objetos de reflexión. Sería bueno si hubiera una interfaz que unifica campos y propiedades (no indexadas).