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

[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.