Arquitectura:Todo lo que se puede hacer con Code First,se puede hacer con Database Fi

[chcma]

Hola foreros !!!

Llevo desde hace tiempo que está teniendo mucho nombramiento Code First. Y querría saber si es que aporta cosas que no puedan aportar Database First.

Por ejemplo... a la hora de trabajar con Unit To Work, he visto que todos los ejemplos trabajan con Entidades Poco, y que los repositorios se han creado empleando DbSet.

¿En una arquitectura basada en Database First, también se puede trabajar con Unit To Work?

Y bueno... también me gustaría escuchar opiniones de cual es mejor, y si con alguna se pueden hacer más cosas que con otras (A nivel de arquitectura).

Personalmente creo que es mucho mejor Database First, por que diseñar la base de datos en SQL Server, y a partir de ahí tener todo el modelo en el código me parece super cómodo. En vez de tener que crearlo todo a mano mediante código.

Además.. cuando hay alguna actualización de tabla, algún campo, o algo... en Code First tienes que trabajar con Migrations y creo que es bastante tedioso (Hablo desde el desconocimiento, y solo me guío por lo poco que vi).

En fin... agradecería a personas que trabajen en arquitectura y tengan conocimiento me puedan dar sus opiniones y así aprender un poco más.

Gracias y un saludo desde España !!! :)

[agleiva]

Los distintos "flujos de trabajo" (workflows) de Entity Framework están orientados a permitir distintas formas de trabajar, según la preferencia del desarrollador.

Si te orientas más hacia la escritura de SQL y querés controlar exactamente como se crean las tablas, etc, escribiendo vos mismo el SQL, entonces sí DB First parece ser el workflow indicado para vos.

A mí en lo personal, me es muchísimo más rápido utilizar Code First, ya que no me interesa crear manualmente el SQL, si no que me interesa enforcarme en el modelo de negocio del software que estoy escribiendo, y dejar que el ORM se ocupe de los detalles irrelevantes.

Con respecto a Unit Of Work, este patrón se puede implementar usando el Context, irrespectivamente de como se haya generado ese Context.

Con respecto a si DB First o Code First tienen más o menos capacidades, la respuesta es no, ya que en ambos casos estas utilizando Entity Framework con todo lo que eso significa, sólo estas cambiando el workflow.

Con respecto al uso de Migrations, cabe destacar que esto se utiliza al versionar tu aplicación, para crear un mecanismo de upgrade de la base de datos. Es decir, cuando ya tu aplicacion esta en producción y necesitas reemplazarla por una versión nueva que implica cambios en la base, entonces o bien podés usar Migrations, o bien podés modificar la base escribiendo y ejecutando vos mismo scripts de SQL. Todo va en qué flujo de trabajo sea mas comodo.
A diferencia de esto, en el momento de desarrollar tu aplicación, que estás haciendo cambios constantes a la base y al modelo, entonces NO vas a usar Migrations, lo que vas a hacer es usar DropCreateDatabaseAlways<T> o DropCreateDatabaseIfModelChanges<T> para que EF automáticamente elimine y reconstruya la base de datos, o bien cada vez que inicias tu aplicación, o bien cuando detecte que hay cambios en el Model.

[chcma]

Muchas gracias por tu aporte Agleiva,

La verdad que me gusta más centrarme en el código y el negocio, como tú. Sin embargo... ¿No te parece complejo tener que trabajar con Fluent Api para la definición de las tablas, y las relaciones?

Y sobre Migrations.. si tienes una aplicación puesta en producción, y necesitas actualizar una tabla poniéndole, por ejemplo, dos campos nuevos. Esa acción si o sí se debe realizar mediante SQL, ¿Verdad?, ya que con Migrations, según tengo entendido te "Regenera la BBDD", y por lo tanto, pierdes los datos que previamente estuvieran guardados. ¿Estoy en lo correcto?

Bueno.. te agradezco tus puntos de vista. : )

[agleiva]

Iniciado por chcma

¿No te parece complejo tener que trabajar con Fluent Api para la definición de las tablas, y las relaciones?

A decir verdad, no lo veo como algo complejo si no mas bien tedioso y repetitivo, ya que para cada entidad del modelo hay que declarar practicamente las mismas cosas. Por este motivo lo que hice fue automatizar la generación de este código, y no tengo que escribirlo yo mismo si no que tengo un framework que lo hace por mí.

La ventaja de la Fluent API (con respecto a otros mecanismos como por ejemplo usar atributos en las clases del modelo) es que el codigo que utiliza la Fluent API vive en el Context en si mismo, y no genera dependencias indeseadas. Esto quiere decir que las clases del modelo son mucho más portables y pueden funcionar en entornos donde System.Data.Entity.dll no esté disponible.

Iniciado por chcma

sobre Migrations.. si tienes una aplicación puesta en producción, y necesitas actualizar una tabla poniéndole, por ejemplo, dos campos nuevos. Esa acción si o sí se debe realizar mediante SQL, ¿Verdad?, ya que con Migrations, según tengo entendido te "Regenera la BBDD", y por lo tanto, pierdes los datos que previamente estuvieran guardados. ¿Estoy en lo correcto?

No, no es correcto.

Justamente Migrations se trata de actualizar la base de datos, realizando los cambios que sean necesarios, sin perder los datos existentes.

Estas confundiendo Migrations con el mecanismo de DropCreateDataBase que te mencioné antes. Estos dos conceptos son distintos y se usan en momentos diferentes:

- Cuando actualizas una base en Producción, usas Migrations para no perder los datos existentes.
- Cuando estas en el proceso de desarrollar tu software y querés hacer cambios rápidamente sin importarte conservar los datos (ya que igualmente estás usando una base de desarrollo y no una real de Producción), usas DropCreateDataBase porque te permite trabajar mucho más rapido, sin escribir SQL, ni escribir el codigo de la Migration ya que no es necesario.