Generar clases de POCO en un proyecto diferente al proyecto con el modelo de Entity Framework

Estoy tratando de usar el patrón de repository con EF4 usando VS2010.

Para este fin, estoy utilizando la generación de código POCO haciendo clic derecho en el diseñador del modelo de entidad y haciendo clic en Agregar elemento de generación de código. Luego selecciono la plantilla de POCO y obtengo mis clases.

Lo que me gustaría poder hacer es tener mi solución estructurada en proyectos separados para las clases de Entidad (POCO) y otro proyecto para el modelo de entidad y el código de repository.

Esto significa que mi proyecto de MVC podría usar las clases de POCO para vistas fuertemente tipadas, etc. y no tener que saber sobre el repository o tener que hacer referencia a él.

Para conectarlo todo, tendré otro proyecto separado con interfaces y usaré IoC.

Suena bien en mi cabeza. ¡No sé cómo generar las clases en su propio proyecto! Puedo copiarlos y luego cambiar los espacios de nombres en ellos, pero quería evitar el trabajo manual cada vez que cambio el esquema en el archivo db y quiero actualizar mi modelo.

Gracias

En realidad, las plantillas T4 en EF 4.0 fueron diseñadas teniendo en cuenta este escenario 🙂

Hay 2 plantillas:

  • Uno para las Entidades mismas (es decir, ModelName.tt)
  • Uno para ObjectContext (es decir, ModelName.Context.tt)

Debería colocar el archivo ModelName.tt en su proyecto POCO y simplemente cambiar la plantilla para que apunte al archivo EDMX en el proyecto consciente de la persistencia.

Suena raro, lo sé: ahora hay una dependencia, pero está en el tiempo de generación T4, ¡no en tiempo de comstackción! Y eso debería estar bien? Debido a que el conjunto de POCO resultante todavía es completamente persistente ignorante.

Vea los pasos 5 y 6 de esto: http://blogs.msdn.com/adonet/pages/walkthrough-poco-template-for-the-entity-framework.aspx para obtener más información.

Espero que esto ayude

Alex

@Mella,

  1. Para forzar la regeneración de las entidades POCO, solo tiene que hacer clic derecho en el archivo .tt principal y seleccionar “Ejecutar herramienta personalizada”. Esto lo obligará a regenerar sus clases de POCO con sus cambios actualizados en el modelo .edmx.
  2. ¿Hay algún problema con que continúe y haga clic con el botón derecho en el modelo y seleccione “Generar base de datos desde modelo …” aunque no genere necesariamente la base de datos? Es muy probable que se deshaga de su ‘Error 11007 …’.
  3. Creo que es equivalente a un “código detrás”. No sé nada más que eso.

Otra cosa a tener en cuenta sobre el enlace que Alex dio. Una vez que moví mi archivo .tt principal a un proyecto diferente, el archivo que se generó a partir del archivo “.Context.tt” no comstackría porque le faltaban referencias a los archivos POCO que estaban ubicados en un espacio de nombres diferente (porque yo quería mi ObjectContext está en un dominio diferente al de mis archivos POCO). Tuve que modificar el archivo “.Context.tt” para using Poco.Namespace (donde Poco.Namespace es el nombre del espacio de nombres donde se generaron los archivos POCO). Esto luego permitió que mi proyecto comstackra.

Joel

Para el generador EF5 + DbContext: es fácil mover su Name.Context.tt a un proyecto diferente. Sin embargo, deberá hacer referencia a las clases modelo. Puede hacerlo manualmente, pero esto requerirá que lo cambie cada vez que se genere el código. También podría usar el mismo espacio de nombres para ambos proyectos. Esto es válido y funcionará, pero creo que es un mal diseño. Otra alternativa es cambiar la plantilla T4 (Name.Context.tt).

Cambiar esto (línea 43):

 using System; using System.Data.Entity; using System.Data.Entity.Infrastructure; < # if (container.FunctionImports.Any()) { #> 

A esto:

 using System; using System.Data.Entity; using System.Data.Entity.Infrastructure; < # if (modelNamespace != codeNamespace) #> using < #=code.EscapeNamespace(modelNamespace)#>; < # if (container.FunctionImports.Any()) { #> 

Esto verificará si el espacio de nombres de su modelo difiere del espacio de nombres de su código; de ser así, insertará el uso requerido para hacer referencia a las clases de su modelo.

He encontrado un error grave al usar este enfoque combinado con los proyectos y controles de datos dynamics. Básicamente, obtendrás un error.

“No se pudo determinar una MetaTable. No se pudo determinar una MetaTable para la fuente de datos ‘EntityDataSource1’ y no se pudo inferir una de la URL de la solicitud. Asegúrese de que la tabla esté correlacionada con la fuente de las dats o que la fuente de datos esté configurada con un tipo de contexto y un nombre de tabla válidos, o que la solicitud es parte de un DynamicDataRoute registrado. ”