Ho letto su Entity Framework, in particolare, EF 4.1 e seguendo questo link ( link ) e guida su Code First.
Lo trovo pulito, ma mi stavo chiedendo, il Code First dovrebbe essere solo una soluzione per lo sviluppo rapido in cui si può semplicemente saltare a destra senza molta pianificazione o è effettivamente destinato ad essere utilizzato per applicazioni su larga scala?
Potrei avere alcuni detrattori, ma quando ho letto alcuni di questi post di Hanselman e Gutherie, ho letto di Julia Lerman libro su Entity Framework, ho avuto un momento davvero difficile con il codice prima. Nei miei molti anni di applicazioni di costruzione, ho seguito molti percorsi, sia forzatamente per processo, sia per scelta, e ho scoperto che ho molto più successo quando si acquisisce una vista incentrata sui dati quando si costruisce un'applicazione.
Sto parlando della linea di applicazioni aziendali qui ... questo è quando si ha un problema aziendale o un processo che deve avere una soluzione software dietro di esso. Hai dati che devono essere gestiti in qualche modo. È meglio conoscere i tuoi dati e il loro rapporto con se stesso e il modo in cui viene utilizzato all'interno dell'azienda. Pertanto, modellare tali dati e quindi creare un'applicazione / soluzione attorno ad essi. Nella mia esperienza, se inizi a creare l'applicazione con i dati come ripensamenti, qualcosa alla fine viene omesso, e poi hai qualche refactoring (in molti casi - refactoring MAJOR).
Le piccole applicazioni possono costituire un'eccezione, ma continuerò a utilizzare il mio approccio incentrato sui dati.
Non vedo perché CodeFirst non possa essere utilizzato in progetti aziendali di grandi dimensioni. Devo dire che uso EF CodeFirst in diversi progetti, uno in cui il database è generato dal mio modello EF CodeFirst e il secondo dove EF CodeFirst è mappato su un database esistente.
Dalla mia esperienza, l'efficacia di CF in un grande progetto dipende in larga misura dall'astratto livello dei dati dal livello aziendale.
Ad esempio, in uno dei miei progetti il livello aziendale chiama direttamente il database tramite linq. Uso Linq per astrarre il mio livello di database e utilizzare CodeFirst per mappare i miei POCO nello schema del database. In questo caso CodeFirst rende molto più semplice l'atto di mantenere le differenze tra le convenzioni DB (nomi di tabelle e di relazioni) ei miei nomi di classe C # e posso apportare modifiche al database senza influire pesantemente sul modo in cui il mio livello aziendale interagisce con il database.
Tuttavia, in un altro progetto ho astratto l'accesso al database in un modello di repository non generico e i metodi Get * del mio repository sono gli unici responsabili dell'esecuzione di query sul database e restituiscono oggetti reali (non IQueryable<T> s). In questo caso, i metodi di repository convertono le entità DB nelle entità POCO e in questo caso CodeFirst non offre molti vantaggi in quanto i POCO CodeFirst sono di breve durata e vengono rapidamente convertiti in classi C # del livello aziendale.
In definitiva, dipende in realtà da come è strutturato il team e da quanto è comodo il team (o gli anziani) con gli ingegneri non DBA che modificano gli schemi di database e quanto le modifiche dello schema influenzeranno la struttura del codice. Con CodeFirst mappato su un database esistente, è banale per me rimappare una proprietà con un nuovo nome di colonna senza dover fare una rinominazione globale di quel nome di proprietà, che è particolarmente un fattore quando si parla di un nome che ha più senso per un campo di database piuttosto che una proprietà C #. È anche per me banale aggiungere il supporto del codice per i nuovi campi del database senza dover rimodellare completamente le mie entità C # (uno dei motivi per cui ho lasciato Linq-to-sql in EF CodeFirst da un database esistente).
Di solito per i progetti di grandi dimensioni il database è già stato creato. O perché è un database legacy o creato da un dba competente per le prestazioni. L'unico vantaggio di CodeFirst è se non si desidera utilizzare le entità di EF ma invece i POCO.
Code First non è adatto per applicazioni su larga scala. Il turnaround di sviluppo di app su larga scala è enorme.
Normalmente il ciclo di vita della tua app aziendale è come
E ci sono altri ponti di comunicazione Cross Application, alcune attività programmate, alcune integrazioni di terze parti, servizi Web per alcuni dispositivi di comunicazione diversi come il cellulare ecc.
Eventualmente Code First utilizza ObjectContext di Entity Model, EF di generazione maggiore di EDMX e l'utilizzo di ObjectContext con EntityObject era veramente sufficiente per tutto. È possibile personalizzare facilmente il modello di testo per generare codice. Il metodo Detect Changes è più lento con l'implementazione di ObjectContext, ma invece di generare proxy, il team EF avrebbe potuto facilmente migliorare la velocità di rilevamento delle modifiche invece di reinventare prima il codice.
Migrazione automatizzata
La migrazione automatizzata suona bene in teoria, ma è praticamente impossibile una volta che vai in diretta. È utile solo per la prototipazione, sviluppando alcune demo veloci.
Code First Migration non è affatto adatto in tale sistema. Molto probabilmente la versione 1 e la versione 2 parlano allo stesso database. La versione 3 e la versione 4 di solito sono in scena e hanno un database differente.
Database prima
Database First è un approccio pratico, è facile confrontare e visualizzare e mantenere gli script SQL. Gli amministratori di database possono lavorare facilmente.
Modelli di testo
Abbiamo creato i nostri modelli di testo per interrogare e creare EDMX e ObjectContext con una piccola implementazione personalizzata che risolva i problemi di prestazioni. Esistono più applicazioni con più versioni che comunicano allo stesso database senza problemi.
Per me, fare clic con il tasto destro sul file .tt e fare clic su "Esegui strumento personalizzato" è di gran lunga il passo più semplice e veloce, quindi scrivere classi, configurare e creare il modello.
Mi sembra che "Code First" sia pensato per usare EF con più "agile" (non suonare troppo su quel termine, non intendo necessariamente la metodologia) e le app greenfield, dove non si fa " avere un modello di dati esistente o dati esistenti; il tipo di app che potresti utilizzare anche Django, o un framework PHP o Rails per seguire le linee guida di quei framework che normalmente implicano la creazione del modello di dati come parte del codice, invece di costruire un'applicazione attorno a un modello di dati che è il tradizionale Microsoft modo di gestire le cose.
Quindi per rispondere alla domanda direi di no; se hai già dati esistenti e stai creando un'applicazione per gestirli, Code First non ha molto senso. Comunque, e non ho usato molto EF, per non parlare del Code First EF, sembra che si tratti di un approccio al codice più sciolto che è sempre vantaggioso. Supponendo che tu possa usare Code First e poi puntare ancora la classe a un modello dati esistente (invece di essere costretto a generare il modello) l'approccio Code First potrebbe ancora aiutare a scrivere codice correttamente estratto e testabile senza tutto il solito "cruft" dell'uso Entity Framework (cioè i metaclassi generati).
Direi che in progetti molto grandi, il code-first non ha senso.
In effetti, quando il progetto diventa molto grande, spesso si ha una netta separazione delle preoccupazioni. Non è possibile avere la stessa persona che scrive codice C #, crea una progettazione di database, scrive HTML / CSS e fa visual design in Photoshop. Invece, la progettazione del database viene eseguita da un amministratore del database (o almeno da una persona dedicata che conosce il suo lavoro).
Poiché il database è progettato da una persona che ha familiarità con il database, gli strumenti di gestione di SQL e di amministrazione e di database, sarebbe strano vedere questa persona che utilizza Entity Framework.
Inoltre, non sono sicuro che Entity Framework sia abbastanza potente per progettare correttamente il database. Che dire degli indici? Vincoli? Vista?
Il codice prima è valido anche per sistemi di grandi dimensioni: basta esaminare il modello dopo la creazione e rimappare usando l'api fluente fino a raggiungere un modello db che ti piace.
Leggi altre domande sui tag entity-framework codefirst