Quanto è facile aggiornare Entity Model dal database quando è già stato scritto abbastanza codice?

I generatori di codice sono un'arma a doppio taglio. Puoi creare un sacco di codice complesso in modo rapido e semplice, ma devi essere preparato a convivere con il codice che hai generato. Non puoi (non vuoi) personalizzare questo codice perché le tue personalizzazioni verranno cancellate se ti rigenererai mai.

Secondo la mia esperienza, le versioni recenti di EF (ad esempio 4.x) sono perfettamente in grado di rigenerarsi da modifiche a un database.

Finché hai evitato la tentazione di personalizzare il codice generato, starai bene.

C'è un avvertimento, ovviamente. Se le modifiche al lato DB includono modifiche o eliminazioni di elementi precedentemente esistenti, qualsiasi codice che tocchi l'ORM per tali articoli sarà potenzialmente danneggiato. Ciò significa che qualsiasi logica aziendale o codice del livello di presentazione che utilizza oggetti di database modificati potrebbe essere interrotto dopo l'aggiornamento del modello.

Dovrai eseguire un rigoroso test di regressione del codice esistente se una qualsiasi delle tue modifiche al DB toccherà elementi già presenti nel tuo modello a partire dalla generazione precedente.

EntityFramework è stato originariamente progettato con l'approccio "Model-First" come l'approccio preferito per creare il tuo livello di accesso ai dati, tuttavia molti negozi di software sembrano ancora vivere nel Medioevo dove preferiscono progettare lo schema prima e poi il modello per accontentarlo Ok, potrei essere un po 'ingiusto, se hai un'elaborazione intensiva del database in cui le stored procedure avvantaggiano le prestazioni, allora ha senso iniziare dal database e aprirti la strada.

Indipendentemente da ciò, quando ho giocato con la prima versione di EntityFramwork, il supporto per l'aggiornamento del modello dal database esisteva, tuttavia all'inizio era un po 'buggato. Questo è stato anni fa, tuttavia, e ricordo di aver letto che molte di quelle questioni sono state elaborate da allora. Non sento nulla di ciò che EntityFramework viene utilizzato in questo modo.

Is it difficult to track changes and make code work?

Tutto dipende se stai seguendo un'architettura opportunamente stratificata con accoppiamento lento. Idealmente, se il modello EntityFramework cambia, le modifiche nei livelli Data Access e Business Logic dovrebbero essere vincolate ai livelli che utilizzano il modello EntityFramework.

Idealmente se stai praticando TDD, i tuoi test unitari dovrebbero fallire e indicare quali aree devono essere rifatte dopo un cambio di modello.

Recentemente ho fatto alcuni test / progetti di apprendimento con questo e ho scoperto che l'aggiornamento Entity from DB procede senza problemi per la maggior parte. Devi stare attento a scegliere la giusta scelta di scheda e non rovinare tutto usando add piuttosto che aggiornare. Uno svantaggio è che se generi qualcosa di sbagliato, a volte è più facile cancellare e ricominciare da capo piuttosto che provare a correggere i problemi.

Ho trovato che il processo Entity to DB è meno scorrevole, in particolare quando si ha a che fare con un DB SQL compatto. A volte errori strani mi avrebbero costretto a chiudere VS e riavviarlo e, dopo aver fatto ciò, gli script generati funzionavano. Tuttavia, a volte gli script non erano del tutto corretti e lasciavano un indice. Ciò ha richiesto una correzione manuale al DB.

Come menzionato da Joel Brown, si desidera evitare di apportare modifiche al codice generato. Tuttavia, è possibile utilizzare le classi parziali per aggiungere funzionalità, se necessario. L'ho usato per implementare IEquatable per alcune Entità poiché ne avevo bisogno per una routine di livello aziendale.