Pregunta Código primero frente a modelo / base de datos primero


¿Cuáles son los pros y contras de usar Entity Framework 4.1 Code-first sobre Model / Database-first con el diagrama de EDMX?

Estoy tratando de comprender completamente todos los enfoques para construir la capa de acceso a datos usando EF 4.1. Estoy usando un patrón de repositorio y IoC.

Sé que puedo usar el enfoque de primer código: definir mis entidades y contexto a mano y usar ModelBuilder para ajustar el esquema.

También puedo crear un EDMX Diagrama y elegir un paso de generación de código que utiliza plantillas T4 para generar el mismo POCO clases

En ambos casos termino con POCO objeto que son ORM agnóstico y contexto que se deriva de DbContext.

La primera base de datos parece ser la más atractiva, ya que puedo diseñar bases de datos en Enterprise Manager, sincronizar rápidamente el modelo y ajustarlo con el diseñador.

Entonces, ¿cuál es la diferencia entre esos dos enfoques? ¿Se trata solo de la preferencia VS2010 vs Enterprise Manager?


570
2018-03-27 00:17


origen


Respuestas:


Creo que las diferencias son:

Código primero

  • Muy popular porque a los programadores hardcore no les gusta ningún tipo de diseñadores y la definición de mapeo en EDMX xml es demasiado compleja.
  • Control total sobre el código (sin código autogenerado que es difícil de modificar).
  • La expectativa general es que no te molestes con DB. DB es solo un almacenamiento sin lógica. EF se encargará de la creación y no quiere saber cómo funciona.
  • Es muy probable que se pierdan los cambios manuales en la base de datos porque su código define la base de datos.

Base de datos primero

  • Muy popular si tiene DB diseñado por DBA, desarrollado por separado o si tiene DB existente.
  • Dejarás que EF cree entidades para ti y después de la modificación del mapeo generarás entidades POCO.
  • Si desea funciones adicionales en entidades POCO, debe modificar la plantilla T4 o usar clases parciales.
  • Los cambios manuales a la base de datos son posibles porque la base de datos define su modelo de dominio. Siempre puede actualizar el modelo desde la base de datos (esta característica funciona bastante bien).
  • A menudo uso esto juntos en proyectos de VS Database (solo versiones Premium y Ultimate).

Primer modelo

  • En mi humilde opinión, si eres fanático del diseño (= no te gusta escribir código o SQL).
  • Usted "dibujará" su modelo y permitirá que el flujo de trabajo genere su script de base de datos y la plantilla T4 genere sus entidades POCO. Perderá parte del control tanto en sus entidades como en su base de datos, pero para proyectos pequeños y fáciles será muy productivo.
  • Si desea funciones adicionales en entidades POCO, debe modificar la plantilla T4 o usar clases parciales.
  • Es muy probable que se pierdan los cambios manuales en la base de datos porque su modelo define la base de datos. Esto funciona mejor si tiene instalado el paquete de alimentación de generación de base de datos. Le permitirá actualizar el esquema de la base de datos (en lugar de volver a crear) o actualizar los proyectos de la base de datos en VS.

Espero que en el caso de EF 4.1 haya otras funciones relacionadas primero con Code First vs. Modelo / Base de datos. Fluent API utilizada en Code first no ofrece todas las funciones de EDMX. Espero que funciones como el mapeo de procedimientos almacenados, vistas de consultas, definición de vistas, etc., funcionen al usar primero el Modelo / Base de Datos y DbContext(No lo intenté todavía) pero primero no lo hacen en el Código.


642
2018-03-27 01:27



Creo que este simple "árbol de decisiones" de Julie Lerman, el autor de "Programming Entity Framework" debería ayudar a tomar la decisión con más confianza:

a decision tree to help choosing different approaches with EF

Más información aquí.


121
2017-10-09 17:45



La base de datos primero y el modelo primero no tienen diferencias reales. El código generado es el mismo y puede combinar estos enfoques. Por ejemplo, puede crear una base de datos usando el diseñador, que puede alterar la base de datos usando la secuencia de comandos sql y actualizar su modelo.

Cuando usa el código primero, no puede alterar el modelo sin la base de datos de recreación y perder todos los datos. En mi humilde opinión, esta limitación es muy estricta y no permite utilizar el código primero en la producción. Por ahora no es realmente útil.

La segunda desventaja menor del código primero es que el generador de modelos requiere privilegios en la base de datos maestra. Esto no le afecta si usa la base de datos SQL Server Compact o si controla el servidor de la base de datos.

La ventaja del código primero es un código muy limpio y simple. Usted tiene control total de este código y puede modificarlo y usarlo fácilmente como su modelo de vista.

Puedo recomendar usar el primer acercamiento de código cuando crea una aplicación independiente simple sin versionar y usa model \ database primero en proyectos que requieren modificación en la producción.


44
2018-01-31 07:38



Citando las partes relevantes de http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 razones para usar el primer diseño de código con Entity Framework

1) Menos cruft, menos hinchazón

Usar una base de datos existente para generar un archivo de modelo .edmx y   los modelos de código asociados producen una pila gigante de código generado automáticamente.   Se le implora que nunca toque estos archivos generados para que no se rompa   algo, o sus cambios se sobrescribirán en la próxima generación. los   el contexto y el inicializador también están atascados en este lío. Cuando   necesita agregar funcionalidad a sus modelos generados, como   propiedad de solo lectura calculada, necesita extender la clase de modelo.   Esto termina siendo un requisito para casi todos los modelos y terminas   con una extensión para todo.

Con el código primero, sus modelos codificados a mano se convierten en su base de datos. El exacto   los archivos que estás construyendo son los que generan el diseño de la base de datos.   No hay archivos adicionales y no hay necesidad de crear una clase   extensión cuando desee agregar propiedades o cualquier otra cosa que el   la base de datos no necesita saber. Puedes simplemente agregarlos al   misma clase siempre que sigas la sintaxis adecuada. Diablos, puedes incluso   genere un archivo Model.edmx para visualizar su código si lo desea.

2) Mayor control

Cuando vas primero a DB, estás a merced de lo que se genera para   sus modelos para usar en su aplicación. Ocasionalmente el nombramiento   la convención es indeseable. A veces las relaciones y   las asociaciones no son exactamente lo que quieres Otras veces no transitorio   las relaciones con cargas perezosas causan estragos en sus respuestas API.

Si bien casi siempre hay una solución para los problemas de generación de modelos   es posible que te topes, el código que va primero te da completo y bien   gran control desde el principio. Puedes controlar todos los aspectos de ambos   sus modelos de código y su diseño de base de datos desde la comodidad de su   objeto comercial. Puede especificar con precisión las relaciones, las restricciones,   y asociaciones Puede establecer simultáneamente límites de caracteres de propiedad   y tamaños de columna de base de datos. Puede especificar qué colecciones relacionadas   deben estar ansiosos cargados, o no ser serializados en absoluto. En resumen, eres   responsable de más cosas, pero usted tiene el control total de su aplicación   diseño.

3) Control de versión de la base de datos

Este es un grande. Las bases de datos de versiones son difíciles, pero primero con el código   y codifica primeras migraciones, es mucho más efectivo. Porque su   El esquema de la base de datos se basa completamente en sus modelos de código, por versión   controlando su código fuente está ayudando a versionar su base de datos.   Usted es responsable de controlar su inicialización de contexto que   puede ayudarlo a hacer cosas como sembrar datos comerciales fijos. Tu tambien   responsable de crear código primeras migraciones.

Cuando habilita por primera vez las migraciones, una clase de configuración y una inicial   migración generada La migración inicial es tu esquema actual   o su línea base v1.0. A partir de ese momento agregarás migraciones   que están marcados con el tiempo y etiquetados con un descriptor para ayudar con   orden de versiones. Cuando llamas a add-migration desde el paquete   administrador, se generará un nuevo archivo de migración que contiene todo   eso ha cambiado automáticamente en su modelo de código tanto en un UP () y   Función DOWN (). La función UP aplica los cambios a la base de datos,   la función ABAJO elimina esos mismos cambios en el evento que desee   Retroceder. Además, puede editar estos archivos de migración para agregar   cambios adicionales como nuevas vistas, índices, procedimientos almacenados y   cualquier otra cosa. Se convertirán en un verdadero sistema de control de versiones para su   esquema de base de datos.


27
2018-05-09 20:06



Código primero parece ser la estrella ascendente. Eché un vistazo rápido a Ruby on Rails, y su estándar es el primero en el código, con migraciones de bases de datos.

Si está creando una aplicación MVC3, creo que Code primero tiene las siguientes ventajas:

  • Fácil decoración de atributos - Puedes decorar campos con atributos de validación, requiriendo, etc., es bastante incómodo con el modelado EF
  • No hay errores de modelado extraños - El modelado EF a menudo tiene errores extraños, como cuando intenta cambiar el nombre de una propiedad de asociación, necesita coincidir con los metadatos subyacentes, muy inflexible.
  • No es incómodo fusionar - Cuando se usan herramientas de control de versiones de código como mercurial, fusionar archivos .edmx es un problema. Eres un programador utilizado para C #, y ahí estás fusionando un .edmx. No es así con el código primero.
  • Contraste primero al código y tienes un control total sin todas las complejidades ocultas e incógnitas con las que lidiar.
  • Recomiendo que use la herramienta de línea de comandos de Package Manager, ni siquiera use las herramientas gráficas para agregar un nuevo controlador a las vistas de andamio.
  • DB-Migraciones - Entonces también puedes Habilitar-Migraciones. Esto es tan poderoso. Realiza cambios en el modelo en el código y, a continuación, el marco puede realizar un seguimiento de los cambios en el esquema, para que pueda implementar actualizaciones sin problemas, con las versiones del esquema automáticamente actualizadas (y degradadas si es necesario). (No estoy seguro, pero esto probablemente también funciona con modelo primero)

Actualizar

La pregunta también requiere una comparación de código primero para EDMX modelo / db-first. Code-first también se puede usar para ambos enfoques:


25
2017-07-26 02:37



Utilizo la base de datos EF primero para proporcionar más flexibilidad y control sobre la configuración de la base de datos.

Primero, el código EF y el modelo parecían interesantes al principio y proporcionan independencia de la base de datos, sin embargo, al hacerlo no permite especificar lo que considero información de configuración de base de datos muy básica y común. Por ejemplo, índices de tabla, metadatos de seguridad o una clave principal que contiene más de una columna. Me parece que quiero utilizar estas y otras características comunes de la base de datos y, por lo tanto, tengo que hacer alguna configuración de base de datos directamente de todos modos.

Encuentro que las clases de POCO predeterminadas generadas durante la BD son muy limpias, sin embargo, carecen de los atributos de anotación de datos muy útiles o las asignaciones a los procedimientos almacenados. Usé las plantillas T4 para superar algunas de estas limitaciones. Las plantillas T4 son increíbles, especialmente cuando se combinan con sus propios metadatos y clases parciales.

Primero, el modelo parece tener mucho potencial, pero me está dando muchos errores durante la refactorización compleja del esquema de la base de datos. No estoy seguro por qué.


11
2017-09-27 04:16



Trabajar con modelos grandes fue muy lento antes del SP1, (no lo he probado después del SP1, pero se dice que es muy fácil ahora).

Todavía diseñé mis tablas primero, luego una herramienta construida internamente genera las POCO para mí, por lo que toma la carga de realizar tareas repetitivas para cada objeto poco.

Cuando usa sistemas de control de fuente, puede seguir fácilmente el historial de sus POCO, no es tan fácil con el código generado por el diseñador.

Tengo una base para mi POCO, lo que hace que muchas cosas sean bastante fáciles.

Tengo vistas para todas mis tablas, cada vista base trae información básica para mis claves externas y mi vista POCO deriva de mis clases POCO, lo cual es bastante útil de nuevo.

Y finalmente no me gustan los diseñadores.


6
2018-04-01 07:44



Primer ejemplo de base de datos:

Sin escribir ningún código: Primer enfoque / base de datos de ASP.NET MVC / MVC3 primero

Y creo que es mejor que otros enfoques porque la pérdida de datos es menor con este enfoque.


4
2018-03-10 03:33



En mi humilde opinión, creo que todos los modelos tienen un gran lugar, pero el problema que tengo con el primer modelo es que en muchas grandes empresas con DBA controlando las bases de datos, no se obtiene la flexibilidad de crear aplicaciones sin utilizar los primeros enfoques de la base de datos. He trabajado en muchos proyectos y, en lo que respecta al despliegue, querían un control total.

Así que, aunque estoy de acuerdo con todas las variaciones posibles primero en Code First, Model First, Database, debe tener en cuenta el entorno de producción real. Entonces, si su sistema va a ser una gran aplicación de base de usuarios con muchos usuarios y administradores de bases de datos ejecutando el programa, entonces podría considerar la primera opción de la base de datos solo mi opinión.


3
2018-06-23 15:28