Se il tuo obiettivo principale è creare prima le tabelle nel database e poi aggiornare automaticamente il tuo progetto, dovresti usare Database First.
Detto questo, devi considerare gli svantaggi di Database First:nella mia esperienza personale ho smesso di usare quell'approccio principalmente per due motivi:
- Il supporto di Database First verrà interrotto, per quanto ne so. EF Core non include lo strumento Editor. Alcuni link a riguardo:un post di Julie Lerman , la Tabella di marcia EF Core e un annuncio anticipato da Microsoft .
- L'editor del modello presentava diversi bug e stranezze che causavano la rottura del codice di tanto in tanto. Molto probabilmente questi bug non verranno risolti (vedi punto precedente). Cose come cambiare il tipo di un campo esistente, cambiare le chiavi esterne, ecc.
- Ho avuto molti problemi a causa dell'unione del repository del codice sorgente dei file di entità generati automaticamente. Soprattutto (ma non solo) quando più persone stavano lavorando con le stesse entità, quindi stavamo ottenendo conflitti di unione nel codice generato automaticamente. Inoltre, il codice generato automaticamente a volte non veniva estratto correttamente, quindi non era sincronizzato con l'edmx. Non sono sicuro che succeda anche ad altre persone, ma sembra che a volte Visual Studio, l'editor, lo strumento di generazione del codice automatico in background e il gestore del codice sorgente TFS non funzionino bene insieme.
Quindi, se davvero non puoi vivere senza prima creare le tabelle nel database, vai avanti con Database First, ma devi considerare cosa stai perdendo se non usi Code First. Questo approccio è ampiamente raccomandato da un motivo.
Di solito il motivo principale per le persone che utilizzano Database First al giorno d'oggi è l'impossibilità di migrare il codice legacy all'approccio Code First. Per quanto ne so, è ampiamente accettato che Code First sia la strada giusta per andare diversamente. Qui hai un post interessante su questo (anche se è un po' vecchio, scritto per EF 4.1, quando è stato introdotto Code First, tratta i principali pro e contro di ogni approccio).
Una soluzione alternativa potrebbe essere quella di continuare a utilizzare Code First ma anche utilizzare gli strumenti disponibili che generano automaticamente le entità Code First eseguendo il reverse engineering dalle tabelle del database. Con questo puoi comunque generare le tue tabelle direttamente nel database, ma continuare a utilizzare Code First con le migrazioni e tutto il resto. Ecco un post di Julie Lerman su alcuni di questi strumenti . Potrebbero esserci strumenti più recenti, ma non li ho usati e non li conosco.
Nota:la mia esperienza personale con Database First è stata piuttosto negativa e non è durata troppo a lungo. Forse qualcuno con un'esperienza più positiva in questo approccio potrebbe fornire informazioni più utili al riguardo. Sto usando Code First da un po' di tempo ormai e preferisco davvero questo approccio. La mia risposta potrebbe essere un po' di parte.
