Cita:
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.
Cita:
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.