CodeFirst è progettato per applicazioni su larga scala?

Ho letto su Entity Framework, in particolare EF 4.1 e seguendo questo link ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) ed è una guida su Code First.

Lo trovo pulito ma mi chiedevo, Code First dovrebbe essere solo una soluzione per un rapido sviluppo in cui puoi semplicemente entrare senza molta pianificazione o è effettivamente destinato ad essere utilizzato per applicazioni su larga scala?

Potrei avere dei detrattori là fuori, ma quando ho letto alcuni di quei post di Hanselman e Gutherie, poi ho letto il libro di Julia Lerman su Entity Framework, ho avuto un momento davvero difficile con il codice. Durante i miei molti anni di costruzione di applicazioni, ho percorso molti percorsi, sia forzato dal processo che dalla scelta, e ho scoperto che ho molto più successo quando ho una visione incentrata sui dati durante la creazione di un'applicazione.

Sto parlando di applicazioni line-business qui ... questo è quando hai un problema o un processo aziendale che deve avere una soluzione software dietro. Hai dei dati che devono essere gestiti in qualche modo. È meglio conoscere i tuoi dati e come si relazionano con se stesso e come vengono utilizzati all'interno dell'azienda. Pertanto, modellare quei dati e quindi creare un'applicazione / soluzione attorno ad essi. Nella mia esperienza, se inizi a creare l'applicazione con i dati come ripensamento, qualcosa alla fine viene lasciato fuori e quindi hai un refactoring (in molti casi - refactoring MAJOR).

Le piccole applicazioni possono essere un'eccezione, ma continuerò a utilizzare il mio approccio incentrato sui dati.

Non vedo perché CodeFirst non possa essere utilizzato in grandi progetti aziendali. Dirò che utilizzo EF CodeFirst in diversi progetti, uno in cui il database è generato dal mio modello EF CodeFirst e il secondo in cui EF CodeFirst è mappato su un database esistente.

In base alla mia esperienza, l'efficacia della CF in un grande progetto dipende fortemente da quanto il tuo livello dati sia astratto dal tuo livello aziendale.

Ad esempio, in uno dei miei progetti il ​​livello aziendale chiama direttamente il database tramite linq. Uso Linq per sottrarre il mio livello di database e uso 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 relazioni) e i nomi delle mie classi C #, e posso apportare modifiche al database senza dover influire pesantemente sul modo in cui il mio livello aziendale interagisce con il database.

Tuttavia, in un altro progetto ho sottratto 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 del repository stanno convertendo le entità DB in entità POCO e in questo caso CodeFirst non ti offre tanto vantaggio quanto i POCO CodeFirst hanno vita breve e vengono rapidamente convertiti in classi C # di livello aziendale.

In definitiva, dipende davvero da come è strutturato il team e da quanto il team (o gli anziani) sono a proprio agio con gli ingegneri non DBA che modificano gli schemi di database e da quante 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 ridenominazione globale di quel nome di proprietà, il che è particolarmente un fattore quando si parla di un nome che ha più senso per un campo di database anziché una proprietà C #. È anche banale per me aggiungere il supporto del codice per i nuovi campi del database senza dover completamente rimodellare le mie entità C # (uno dei motivi per cui ho lasciato Linq-sql a EF CodeFirst da un database esistente).

Il codice First non è adatto per applicazioni su larga scala. Lo sviluppo di app su larga scala è molto grande.

In genere il ciclo di vita della tua app aziendale è come,

1. La versione 1 è in produzione
2. La versione 2 è in beta
3. La versione 3 è in sviluppo attivo
4. La versione 4 è in programma.

E ci sono altri ponti di comunicazione tra le applicazioni, alcune attività pianificate, l'integrazione di terze parti, servizi Web per alcuni diversi dispositivi di comunicazione come dispositivi mobili, ecc.

Alla fine Code First utilizza ObjectContext di Entity Model, la generazione di EDMX EF precedente e l'utilizzo di ObjectContext con EntityObject sono stati davvero sufficienti per tutto. È possibile personalizzare facilmente il modello di testo per generare codice. Il metodo di rilevamento delle modifiche è 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 anziché reinventare prima il codice.

Migrazione automatizzata

La migrazione automatizzata suona bene in teoria, ma impossibile in pratica una volta che vivi. È buono solo per la prototipazione, sviluppando alcune demo veloci.

Code First Migration non è affatto adatto in tale sistema. La versione 1 e la versione 2 probabilmente parlano allo stesso database. La versione 3 e la versione 4 sono in genere in fase di gestione temporanea e hanno database diversi.

Prima il database

Database First è un approccio pratico, è facile confrontare, visualizzare e gestire gli script SQL. I DBA possono lavorare facilmente.

Modelli di testo

Abbiamo creato i nostri modelli di testo per eseguire query e creare EDMX e ObjectContext con una piccola implementazione personalizzata che risolve i problemi di prestazioni. Esistono più applicazioni con più versioni che comunicano senza problemi allo stesso database.

Per me, fare clic destro sul file .tt e fare clic su "Esegui strumento personalizzato" è di gran lunga il passo più veloce e più semplice quindi scrivere classi, configurare e creare un modello.

Di solito per 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à EF ma i POCO.

Mi sembra che "Code First" sia pensato per usare EF con più "agile" (non arpionare troppo su quel termine, non intendo necessariamente la metodologia) e le app greenfield, dove non hai un modello di dati esistente o dati esistenti; il tipo di app che potresti usare anche Django, o un framework PHP, o Rails per seguire le linee guida di quei framework che normalmente comportano la creazione del modello di dati come parte del codice, invece di creare un'applicazione attorno a un modello di dati che è il tradizionale Modo Microsoft di gestire le cose.

Quindi per rispondere alla domanda direi di no; se disponi già di dati esistenti e stai creando un'applicazione per gestirli, Code First non ha molto senso. Tuttavia, e non ho usato molto EF, per non parlare del Code First EF, sembra che sia un approccio al codice più vagamente accoppiato che è sempre vantaggioso. Supponendo che tu possa usare Code First e quindi puntare ancora la classe a un modello di dati esistente (invece di essere costretto a generare il modello) l'approccio Code First potrebbe comunque aiutare a scrivere codice correttamente astratto e testabile senza la solita "cruft" dell'uso Entity Framework (ovvero i metaclassi generati).

Direi che in progetti davvero grandi, il codice in primo luogo non ha senso.

In effetti, quando il progetto diventa molto grande, spesso si ha una stretta separazione delle preoccupazioni. Non puoi avere la stessa persona che scrive codice C #, progetta database, scrive HTML / CSS e progetta 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, SQL e gli strumenti di amministrazione e progettazione del database, sarebbe strano vedere questa persona utilizzando Entity Framework.

Inoltre, non sono sicuro che Entity Framework sia abbastanza potente da progettare correttamente il database. Che dire degli indici? Vincoli? Visualizzazioni?

Il codice prima è praticabile 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.