Ciao,
fededi ha scritto:
Non corro il rischio che l'allineamento automatico della struttura del DB di una applicazione rilevi alcune tabelle non presenti nelle sue definizioni come estranee e quindi le elimini?
La perdita di dati in produzione è questione grave e ovviamente il team di sviluppo di Entity Framework l'ha tenuta in seria considerazione e ha fatto in modo che ciò non capitasse accidentalmente. Non puoi perdere dati a meno che, ovviamente, non sia stato tu stesso a dare questa esplicita disposizione (non può capitare per caso). Quindi da questo punto di vista non corri rischi. Casomai ti va in errore l'applicazione per incongruenze tra il modello concettuale e il modello relazionale.
fededi ha scritto:
Si possono gestire più "piani" di definizione di tabelle?
Sì, più DbContext possono accedere allo stesso database, non c'è problema. Per ciascun DbContext, puoi decidere cosa mappare. Magari vuoi esporre solo alcune tabelle e solo alcuni campi da ogni tabella.
La vera questione è ragionare bene sul come aggiornare i modelli una volta che la tua applicazione è in produzione.
Ad esempio: ti serve una colonna in più sulla tabella Clienti ma solo per le applicazioni A e C. Come procedi? Preferisci aggiornare il database manualmente e poi aggiornare le classi del modello per farne uso, oppure il contrario, avvalendoti di EF Migrations (che secondo me in questa situazione sarebbe più complicato)?
ciao,
Moreno
Modificato da BrightSoul il 29 novembre 2015 10.53 -
