3 razones para usar el primer diseño de código con Entity Framework
1) Menos cruft, menos hinchazón
El uso de una base de datos existente para generar un archivo de modelo .edmx y los modelos de código asociados da como resultado un montón gigante de código generado automáticamente. Le imploramos que nunca toque estos archivos generados para que no rompa algo o sus cambios se sobrescriban en la próxima generación. El contexto y el inicializador también están atascados en este desastre. Cuando necesita agregar funcionalidad a sus modelos generados, como una propiedad calculada de solo lectura, 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. Los archivos exactos que está creando son los que generan el diseño de la base de datos. No hay archivos adicionales y no es necesario crear una extensión de clase cuando desea agregar propiedades o cualquier otra cosa que la base de datos no necesite saber. Puede agregarlos a la misma clase siempre que siga la sintaxis adecuada. Diablos, incluso puede generar un archivo Model.edmx para visualizar su código si lo desea.
2) mayor control
Cuando va a DB primero, está a merced de lo que se genera para que sus modelos se usen en su aplicación. Ocasionalmente, la convención de nomenclatura es indeseable. A veces las relaciones y asociaciones no son exactamente lo que quieres. Otras veces, las relaciones no transitorias con carga lenta causan estragos en sus respuestas API.
Si bien casi siempre hay una solución para los problemas de generación de modelos con los que puede encontrarse, el código inicial primero le brinda un control completo y detallado desde el principio. Puede controlar cada aspecto de 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 relaciones, 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 se cargarán ansiosamente o no se serializarán en absoluto. En resumen, usted es responsable de más cosas, pero tiene el control total del diseño de su aplicación.
3) Control de versión de la base de datos
Este es un grande. El control de versiones de las bases de datos es difícil, pero con las migraciones de código primero y código primero, es mucho más efectivo. Debido a que el esquema de su base de datos se basa completamente en sus modelos de código, al controlar la versión de 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 la semilla de datos comerciales fijos. También es responsable de crear las primeras migraciones de código.
Cuando habilita las migraciones por primera vez, se genera una clase de configuración y una migración inicial. La migración inicial es su esquema actual o su línea base v1.0. A partir de ese momento, agregará migraciones que están marcadas con el tiempo y etiquetadas con un descriptor para ayudar con el pedido de versiones. Cuando llame a add-Migration desde el administrador de paquetes, se generará un nuevo archivo de migración que contiene todo lo que ha cambiado en su modelo de código automáticamente en las funciones UP () y DOWN (). La función ARRIBA aplica los cambios a la base de datos, la función ABAJO elimina esos mismos cambios en el caso de que desee revertir. 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 versiones para su esquema de base de datos.
