Volver a EF FAQ tabla de contenido

¿Es necesario utilizar la herramienta de generación de código? ¿Puedo crear entidades a mano?


El Entity Framework no requiere la generación de código. Hay facilidades para la generación de código, y algunos de la superficie de la interfaz de usuario/diseñador se orienta hacia los escenarios porque funcionan bien en una serie de situaciones, pero también es posible crear sus propias clases a mano y usar Entity Framework de esa manera.

EF 4 soporta POCO. Esto significa que puede utilizar objetos CLR simples (""POCO"", en inglés), tales como objetos de dominio existentes, con su modelo de datos. Estas clases de datos POCO (también conocido como objetos ignorantes de persistencia), que se asignan a las entidades que se definen en un modelo de datos, apoyan la mayor parte de las mismas acciones de inserción, actualización y eliminación como tipos de entidad que se generan por las herramientas de Entity Data Model. Para obtener más información, consulte trabajando con entidades POCO .

EF 3.5 SP1 soporta IPOCO. Es decir, puede tener clases que no se heredan de una clase base de EF, pero deben implementar determinadas interfaces y deben tener atributos específicos para trabajar con el EF. Para obtener más información, consulte aplicación personalizada clase Interfaces de datos (Entity Framework) .

¿De http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID = 573966 & SiteID = 1

¿Se recomienda modificar las clases generadas por herramienta?

No, porque si lo hace, entonces no podrá regenerarlas sin perder los cambios.

Para obtener información acerca de cómo evitar sobrescribir personalizaciones a la capa de objeto, consulte Cómo: personalizar genera objetos de datos (Entity Framework) .

¿De http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID = 573966 & SiteID = 1

¿Entity Framework requiere objetos con constructores públicos vacíos?

Mientras que las clases predeterminada generada tienen un constructor sin parámetros público automáticamente suministrado, hay nada en el marco que exige que sea pública. Debe haber un constructor sin parámetros, pero puede ser interno o privado. Puede probar un ejemplo sencillo tomando las clases generadas y añadiendo en un constructor sin parámetros privado. En ese momento el método generado fábrica trabajará para crear instancias para los usuarios, pero el sistema utilizará el constructor sin parámetros privado para materializar objetos que son el resultado de las consultas.

¿De http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID = 573966 & SiteID = 1

¿Entity Framework requiere que propiedades tengan acceso públicos en los objetos que se van a almacenar en la base de datos? ¿Entity Framework admite propiedades de sólo lectura?

El sistema no requiere públicas propiedades configurables para todos los campos que se almacenan en la base de datos. Mientras que las clases predeterminados generados tienen propiedades públicas para cada campo almacenado, puede escribir sus propias clases o establecer el acceso para el captador y definidor en el diseñador (pública, interior, protected o private). Entity Framework no, sin embargo, admite propiedades que sólo tienen captadores y definidores no, y no es compatible con las clases que tienen sólo no propiedades y campos.

¿Entity Framework soporta un campo privado para ser asignado a la base de datos?

El sistema no permite actualmente persisten directamente a un campo. Como se señaló anteriormente, sin embargo, puede simplemente hacer el generado propiedad privada.

¿Entity Framework admite la herencia de métodos o propiedades que no se asignan a la base de datos?

Sin duda. Puede agregar estas propiedades o métodos a las clases parciales para los objetos de datos o directamente en las clases POCO. Ellos no se conservará, pero les heredan los tipos derivados.

¿De http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID = 573966 & SiteID = 1

¿Cuáles son los tipos de entidad compatibles con Entity Framework?

Para obtener información acerca de los tipos de entidades diferentes y algunas consideraciones de rendimiento, consulte trabajar con objetos .

¿Cuando debo utilizar entidades self-tracking y cuando son tipos

derivados de EntityObject o clases POCO una mejor opción?


Seguimiento de entidades self-tracking de uso cuando están desarrollando una aplicación de n niveles donde se serializa entidades a un nivel desconectado y entonces necesita serializarles atrás con los cambios. Tenga en cuenta que self-tracking entidades disponen de carga perezosa desactivado por defecto. Para cargar objetos relacionados, utilizar deseoso de carga con el método de inclusión.

Si no necesita serializar los objetos a un nivel desconectado, escribir sus propias clases POCO o tipos de EntityObject derivado. El ADO.NET Entity Data Model herramientas generan tipos de entidad de EntityObject derivado de forma predeterminada, porque estas clases proporcionan automáticamente una serie de servicios: el contexto del objeto gestiona las relaciones entre los objetos, registra los cambios que se producen y soporta carga diferida de la manera más eficiente. Clases POCO por otro lado dan al desarrollador el máximo control sobre sus entidades.

¿Por qué el estado de una entidad self-tracking no se actualize a ""Modified"" después de que su propiedad ha sido modificada en el cliente?

Siempre debe asegurarse de que su cliente hace referencia a los tipos de entidad self-tracking (STEs) y no WCF tipo de proxy generado al agregar referencia de servicio. Para obtener más información, consulte Tutorial: serializar entidades de Self-Tracking .

¿Cómo puedo almacenar un conjunto de entidades self-tracking en ViewState para una aplicación ASP.NET?

Consulte el blog siguiente: http://blogs.msdn.com/b/adonet/archive/2010/05/26/using-binary-serialization-and-viewstate-with-self-tracking-entities.aspx .

¿Dónde puedo encontrar una solución de iterador gráfico para entidades self-tracking?

Consulte el blog siguiente: http://blogs.msdn.com/b/adonet/archive/2010/06/02/working-with-sets-of-self-tracking-entities.aspx .

¿Cómo puedo evitar obtener objetos con claves duplicadas en el gráfico cuando se trabaja con entidades self-tracking?

El siguiente blog describe diferentes enfoques para evitar tener claves duplicadas en el gráfico: http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx .

¿Cómo puedo utilizar entidades self-tracking en Silverlight?


Consulte el blog siguiente: http://blogs.msdn.com/b/adonet/archive/2010/05/14/self-tracking-entities-in-silverlight.aspx .

¿Por qué no funciona Function Import al generar código con la plantilla ""Entidad Self-Tracking generador""?


Después de crear un nuevo modelo EDMX e importar una función, se generan las funciones en el diseñador. Si se realiza la misma acción utilizando ADO.NET Self-Tracking entidad generador plantilla la definición de función se pierde, aunque el archivo .tt contiene la región de la "Función de importaciones".

Lamentablemente esto es un error en la plantilla de la entidad self-tracking. El equipo EF espera tener pronto una versión actualizada disponible con esto y algunas otras actualizaciones. Por el momento, puede copiar el código que genera que la función de las importaciones procedentes de la ADO por defecto.NET EntityObject generador plantilla. Ver una corrección propuesta por Morten: http://pastebin.com/sLbECkBg .

¿Cómo puedo saber qué estrategia de seguimiento de cambios se utiliza: seguimiento con servidores proxy o una instantánea de los cambios?


Hay ocasiones cuando le gustaría probar si su objeto POCO es realmente un proxy. Cuando se crea una entidad POCO mediante el método CreateObject, si el tipo POCO no cumple los requisitos descritos en requisitos para crear POCO Proxies (Entity Framework) , se creará una entidad POCO en lugar de un objeto proxy. Para obtener más información, consulte http://msdn.microsoft.com/en-us/library/ee835846.aspx .

¿Por qué mis entidades no son proxies de seguimiento de cambios, a pesar de todas las propiedades son virtuales?

Una razón común para no obtener a proxies de seguimiento de cambios, incluso si ha realizado las propiedades de todos su entidad virtual es que no has hecho colección de su entidad propiedades de navegación de tipo ICollection. Para obtener más información, consulte http://msdn.microsoft.com/en-us/library/dd468057.aspx .

¿Cómo se rastrean propiedades de tipo complejo en POCO proxies?


Si una entidad POCO contiene una propiedad de tipo complejo, se detectan cambios en los miembros de la instancia del tipo complejo mediante el método de copia instantánea incluso si la entidad tiene un proxy de seguimiento de cambios. Sin embargo, si una instancia nueva del tipo complejo se asigna a una propiedad, el cambio de la propiedad se realiza un seguimiento de la misma manera que otras propiedades.

Una de las reglas de creación de proxy es que todas las propiedades deben marcarse como virtuales. Así, las propiedades de tipo complejo deben ser virtuales, aunque no toman ventaja de seguimiento de cambios basados en la notificación.

¿Hay alguna consideraciones de rendimiento cuando se utiliza POCO?


Cuando se trabaja con objetos POCO, puede mejorar el rendimiento de seguimiento de cambios mediante la creación de proxies POCO seguimiento de cambios. Objetos proxy POCO seguimiento de cambios notificarán Entity Framework acerca de los cambios que se produzcan. También puede utilizar el cambio informes modelo que implica informar un cambio pendiente a una propiedad, estableciendo la propiedad y luego informar que el cambio es completo mediante la interfaz IEntityChangeTracker. Para obtener más información, consulte resolución de identidad, administración del Estado y seguimiento de cambios y seguimiento de cambios en las entidades POCO .

¿Son vistas pre-generadas disponibles cuando se trabaja con POCO?


Sí. Ya vistas, compilado consultas LINQ y metadatos automáticos caché trabajos con POCO en la misma forma que EntityObjects generado.

¿Cuáles son los diferentes opciones para personalizar objetos de entidad?


Las herramientas de Entity Framework generan clases parciales. Tener clases parciales permite ampliar estas clases mediante propiedades y métodos personalizados en un archivo fuente independiente sin tener que preocuparse de perder su personalización cuando se actualizan los archivos generados. Para obtener más información, consulte Cómo: personalizar objetos de datos generado .

También debe considerar el uso de plantillas T4 con el ADO.NET Entity Data Model Designer personalizar genera clases de datos. Para obtener más información, consulte Cómo: personalizar la generación de código de objeto capa .

También puede agregar lógica empresarial para aplicaciones de Entity Framework controlando los eventos que se disparan durante determinadas operaciones, como los cambios en las propiedades o relaciones. Para la lista de eventos y ejemplos, vea definición de lógica de negocios .

Otra opción es utilizar clases de datos personalizadas con su modelo de datos sin hacer modificaciones en las clases de datos propios, como los nombres de las propiedades en las clases de datos personalizados, tipos complejos y tipos de entidad coinciden con los nombres de los tipos de entidad, tipos complejos y propiedades en el modelo conceptual. Esto le permite utilizar POCOs, tales como objetos de dominio, con su modelo de datos. Para obtener más información, consulte trabajando con POCO entidades (Entity Framework) . Puede utilizar la plantilla POCO para generar tipos de entidad ignorante de la persistencia de un modelo conceptual. La plantilla no se incluye con Visual Studio, pero puede descargarse desde el Visual Studio Gallery .

¿Apoya el Entity Framework la clonación de objetos de entidad o tengo que hacerlo manualmente?


Depende. Si sabes que la entidad de referencia tiene relaciones de carga, puede clonar utilizando algo como la serialización binaria estándar. Sin embargo, si no está seguro, es la opción más segura hacer un clon memberwise manual de los datos que necesita.

Volver a EF FAQ tabla de contenido