2011-10-11 33 views
5

Estoy evaluando Entity Framework para un proyecto en comparación con una base de datos heredada. La base de datos está bastante bien diseñada y ya se ha decidido que usaríamos el enfoque Primero de la base de datos. La aplicación estaría basada en WinForms, pero me gustaría planificar y tener en cuenta ASP.Net, así como también es probable que la administración la solicite en algún momento y me gustaría reutilizar el DAL.Confundido sobre generadores para Entity Framework 4.1

Ahora, entiendo que Entity Framework proporciona varias maneras de objetos que se genere la entidad:

  • objetos derivados de EntityObject
  • POCO (ObjectContext)
  • POCO (DbContext)
  • Auto -Organizaciones de seguimiento (STE)

He estado tratando de comparar los tres enfoques y he fundado d esto hasta ahora.

La plantilla EntityObject T4 es la más rica de todas. Por ejemplo, pone los comentarios del modelo de entidad en comentarios de XMLDoc sobre cada clase y cada propiedad de la entidad, lo cual es bastante útil y útil en términos de mantenimiento del código. Ninguno de los otros generadores lo admite de fábrica (aunque entiendo que es posible modificar las plantillas T4, pero obviamente requiere algo de trabajo). Por otro lado, la API DbContext es algo más agradable.

Los tipos derivados de EntityObject proporcionan un evento al que se puede conectar cuando cambia la propiedad de una entidad, lo cual es útil para implementar la lógica comercial.

Entiendo que POCO es más natural para esto, pero el generador T4 sobrescribirá todos mis cambios cada vez que cambie el modelo. Claro, las POCO generadas son clases parciales, pero que yo sepa, no es posible anular una propiedad ya definida en una clase parcial, por lo que no estoy seguro de cómo se está llevando a cabo la implementación de la lógica empresarial en ellas.

Mucha gente parece odiar las clases derivadas de EntityObject, prefiriendo el enfoque POCO, pero parece que estoy perdiendo muchas funciones útiles que proporciona EntityObjects, yendo la ruta POCO. Teniendo en cuenta la gran preferencia general sobre los objetos POCO, puedo estar malentendiendo algo, por lo tanto, mi pregunta.

Por último, ¿qué generador es el más adecuado en un entorno ASP.Net? ¿Me preocupan los cambios de mi entidad que dejan de ser rastreados? ¿Son las Entidades de seguimiento automático más útiles en este caso o solo tienen valor con los servicios web (que probablemente no utilizaré)?

Muchas gracias de antemano.

Respuesta

7

Si desea utilizar EF 4.1, sus opciones son solo DbContext Generator. Todos los demás generadores (POCO, EntityObject y STE) son para ObejctContext API (EF 4.0). Describí las diferencias entre los generadores here.

En su caso, el generador de EntityObject se puede utilizar para WinForms pero será engorroso para la solución de ASP.NET donde las POCO son mejores porque la aplicación ASP.NET es un escenario separado: tendrá que ocuparse del seguimiento de cambios en ASP.NET de todos modos .

El propósito de las STEs se describe en here pero no son muy útiles en WinForm donde puede usar entidades adjuntas directamente o ASP.NET donde demands to store them entre solicitudes en estado de visualización.

Cualquier lógica de negocio que desea poner en la entidad directamente deben ser codificados en el generador de T4 de lo contrario, será reemplazado después de cada generación. Todas las características del generador basado en EntityObject que mencionó pueden implementarse también en el generador POCO/DbContext.

+1

Gracias. Eso es útil. Por "Cualquier lógica de negocios que desee colocar en la entidad directamente debe codificarse en generador T4", ¿quiere decir que necesito modificar la plantilla T4 para que genere los eventos similares al Encendido [Propiedad] Modificado de los EntityObjects? He hecho algunos cambios en un T4 una vez y no puedo decir que fue una experiencia divertida. Teniendo esto en cuenta, estoy sorprendido de no ver más scripts EF T4 compartidos, sino solo los MS-ones. Además, me preocupa que los eventos probablemente no se generen en un entorno ASP.Net, ¿lo harán (cuando los datos se vuelvan a publicar en el servidor)? –

+0

"Cualquier lógica de negocio que desee colocar directamente en la entidad debe codificarse en el generador T4; de lo contrario, se sobrescribirá después de cada generación" <---- Esto no es cierto. Debe colocar la lógica comercial en un archivo de clase parcial ** por separado, y se conservará sin problemas. Todos los generadores anteriores generan clases parciales. – Bobson

+0

@Bobson: ¿Has leído la pregunta? Estamos discutiendo lógica adicional en propiedades generadas. Todavía hay escenarios en los que la clase parcial o incluso los métodos parciales no ayudan. –

Cuestiones relacionadas