Code-first vs modello/database-first [chiuso]

StackOverflow https://stackoverflow.com/questions/5446316

Domanda

Quali sono i vantaggi e gli svantaggi dell'utilizzo di Entity Framework 4.1 Code-first rispetto al modello/database-first con il diagramma EDMX?

Sto cercando di comprendere appieno tutti gli approcci alla creazione del livello di accesso ai dati utilizzando EF 4.1.Sto utilizzando il modello di repository e IoC.

So che posso usare l'approccio code-first:definire le mie entità e il contesto manualmente e utilizzarli ModelBuilder per mettere a punto lo schema.

Posso anche creare un file EDMX diagramma e scegliere un passaggio di generazione del codice che utilizzi i modelli T4 per generare lo stesso POCO classi.

In entrambi i casi mi ritrovo con POCO oggetto che sono ORM agnostico e contesto da cui deriva DbContext.

Il database-first sembra essere molto interessante poiché posso progettare il database in Enterprise Manager, sincronizzare rapidamente il modello e perfezionarlo utilizzando il designer.

Allora qual è la differenza tra questi due approcci?Si tratta solo della preferenza VS2010 rispetto a Enterprise Manager?

È stato utile?

Soluzione

Penso che le differenze siano:

Prima il codice

  • Molto popolare perché ai programmatori più accaniti non piace nessun tipo di designer e la definizione della mappatura in EDMX xml è troppo complessa.
  • Pieno controllo sul codice (nessun codice generato automaticamente difficile da modificare).
  • L'aspettativa generale è che non ti preoccupi di DB.DB è solo un archivio senza logica.EF gestirà la creazione e non vuoi sapere come svolge il lavoro.
  • Molto probabilmente le modifiche manuali al database andranno perse perché il codice definisce il database.

Prima la banca dati

  • Molto popolare se si dispone di DB progettati da DBA, sviluppati separatamente o se si dispone di DB esistenti.
  • Consentirai a EF di creare entità per te e dopo la modifica della mappatura genererai entità POCO.
  • Se desideri funzionalità aggiuntive nelle entità POCO, devi modificare il modello T4 o utilizzare classi parziali.
  • Sono possibili modifiche manuali al database perché il database definisce il modello di dominio.Puoi sempre aggiornare il modello dal database (questa funzionalità funziona abbastanza bene).
  • Lo uso spesso insieme ai progetti VS Database (solo versione Premium e Ultimate).

Prima il modello

  • IMHO popolare se sei un fan dei designer (= non ti piace scrivere codice o SQL).
  • "Disegnerai" il tuo modello e lascerai che il flusso di lavoro generi lo script del tuo database e il modello T4 generi le tue entità POCO.Perderai parte del controllo sia sulle tue entità che sul database, ma per progetti piccoli e facili sarai molto produttivo.
  • Se desideri funzionalità aggiuntive nelle entità POCO, devi modificare il modello T4 o utilizzare classi parziali.
  • Molto probabilmente le modifiche manuali al database andranno perse perché il modello definisce il database.Funziona meglio se è installato il power pack per la generazione di database.Ti consentirà di aggiornare lo schema del database (invece di ricrearlo) o di aggiornare i progetti di database in VS.

Prevedo che nel caso di EF 4.1 ci siano molte altre funzionalità relative a Code First vs.Prima il modello/database.L'API Fluent utilizzata in Code First non offre tutte le funzionalità di EDMX.Mi aspetto che funzionalità come la mappatura delle procedure memorizzate, le visualizzazioni delle query, la definizione delle visualizzazioni ecc.funziona quando si utilizza prima Modello/Database e DbContext (Non l'ho ancora provato) ma non lo fanno prima nel codice.

Altri suggerimenti

Penso che questo semplice "albero decisionale" di Julie Lerman, autrice di "Programming Entity Framework", dovrebbe aiutare a prendere la decisione con maggiore sicurezza:

a decision tree to help choosing different approaches with EF

Ulteriori informazioni Qui.

Prima il database e prima il modello non presentano differenze reali.Il codice generato è lo stesso ed è possibile combinare questi approcci.Ad esempio, puoi creare un database utilizzando Designer, quindi puoi modificare il database utilizzando lo script SQL e aggiornare il tuo modello.

Quando si utilizza prima il codice, non è possibile modificare il modello senza ricreare il database e perdere tutti i dati.IMHO, questa limitazione è molto severa e non consente di utilizzare prima il codice nella produzione.Per ora non è veramente utilizzabile.

Il secondo svantaggio minore del codice prima è che il generatore di modelli richiede privilegi sul database principale.Ciò non influisce se utilizzi il database SQL Server Compact o se controlli il server database.

Il vantaggio del codice è innanzitutto il codice molto pulito e semplice.Hai il pieno controllo di questo codice e puoi modificarlo e utilizzarlo facilmente come modello di visualizzazione.

Posso consigliare di utilizzare l'approccio Code First quando si crea una semplice applicazione autonoma senza controllo delle versioni e si utilizza prima modello\database in progetti che richiedono modifiche in produzione.

Citando le parti rilevanti da http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 motivi per utilizzare la progettazione Code First con Entity Framework

1) Meno cruft, meno gonfio

L'uso di un database esistente per generare un file modello .edmx e i modelli di codice associati si traducono in una pila gigante di codice generato automaticamente.Sei implorato di non toccare mai questi file generati per non interrompere qualcosa, o le tue modifiche vengono sovrascritte nella prossima generazione.Il contesto e l'inizializzatore sono bloccati insieme anche in questo casino.Quando è necessario aggiungere funzionalità ai modelli generati, come una proprietà solo lettura calcolata, è necessario estendere la classe del modello.Questo finisce per essere un requisito per quasi tutti i modelli e finisci con un'estensione per tutto.

Con Code First i tuoi modelli codificati a mano diventano il tuo database.I file esatti che stai costruendo sono ciò che genera il design del database.Non ci sono file aggiuntivi e non è necessario creare un'estensione di classe quando si desidera aggiungere proprietà o qualsiasi altra cosa che il database non abbia bisogno di sapere.Puoi semplicemente aggiungerli nella stessa classe purché segui la sintassi corretta.Diamine, puoi persino generare un file Model.edmx per visualizzare il tuo codice se lo desideri.

2) Maggiore controllo

Quando vai per primo DB, sei in balia di ciò che viene generato per i tuoi modelli per l'uso nella tua applicazione.Occasionalmente la convenzione di denominazione è indesiderabile.A volte le relazioni e le associazioni non sono proprio quello che vuoi.Altre volte le relazioni non transitorie con il caricamento pigro provocano il caos sulle risposte dell'API.

Mentre esiste quasi sempre una soluzione per i problemi di generazione del modello in cui potresti riscontrare, andare in codice prima ti dà un controllo completo e a grana fine fin dall'inizio.Puoi controllare ogni aspetto dei modelli di codice e del design del database dal comfort del tuo oggetto aziendale.È possibile specificare con precisione relazioni, vincoli e associazioni.È possibile impostare contemporaneamente i limiti dei caratteri della proprietà e le dimensioni della colonna del database.È possibile specificare quali raccolte correlate devono essere caricate desiderose o non essere affatto serializzate.In breve, sei responsabile di più cose ma sei in pieno controllo del design della tua app.

3)Controllo della versione del database

Questo è grosso.I database di versione sono difficili, ma con il codice primo e le prime migrazioni del codice, è molto più efficace.Poiché lo schema del database è completamente basato sui modelli di codice, per la versione controllando il codice sorgente che stai aiutando a versione del database.Sei responsabile del controllo dell'inizializzazione del contesto che può aiutarti a fare cose come i dati aziendali fissi di seed.Sei anche responsabile della creazione di prime migrazioni di codice.

Quando si abilitano per la prima volta le migrazioni, vengono generate una classe di configurazione e una migrazione iniziale.La migrazione iniziale è il tuo schema attuale o la tua linea di base v1.0.Da quel momento in poi aggiungerai migrazioni che sono timestamp ed etichettate con un descrittore per aiutare a ordinare le versioni.Quando si chiama ADD-migration dal gestore dei pacchetti, verrà generato un nuovo file di migrazione contenente tutto ciò che è cambiato nel modello di codice automaticamente in una funzione UP () e Down ().La funzione UP applica le modifiche al database, la funzione down rimuove le stesse modifiche nel caso in cui si desidera rollback.Inoltre, è possibile modificare questi file di migrazione per aggiungere ulteriori modifiche come nuove viste, indici, procedure memorizzate e qualsiasi altra cosa.Diventeranno un vero sistema di versioning per lo schema del database.

Code-first sembra essere la stella nascente.Ho dato una rapida occhiata a Ruby on Rails e il loro standard è code-first, con migrazioni di database.

Se stai creando un'applicazione MVC3, credo che Code First presenti i seguenti vantaggi:

  • Decorazione semplice degli attributi - Puoi decorare i campi con convalida, richiesta, ecc.attributi, è piuttosto complicato con la modellazione EF
  • Nessun errore di modellazione strano - La modellazione EF presenta spesso errori strani, ad esempio quando si tenta di rinominare una proprietà di associazione, è necessario che corrisponda ai metadati sottostanti, operazione molto poco flessibile.
  • Non è imbarazzante unirli - Quando si utilizzano strumenti di controllo della versione del codice come Mercurial, l'unione di file .edmx è una seccatura.Sei un programmatore abituato a C# e stai unendo un .edmx.Non è così con il code-first.
  • Confronta prima il codice e avrai il controllo completo senza tutte le complessità nascoste e le incognite da affrontare.
  • Ti consiglio di utilizzare lo strumento da riga di comando Gestione pacchetti, di non utilizzare nemmeno gli strumenti grafici per aggiungere un nuovo controller alle visualizzazioni dello scaffold.
  • Migrazioni DB - Quindi puoi anche abilitare le migrazioni.Questo è così potente.Apporta modifiche al modello nel codice e quindi il framework può tenere traccia delle modifiche dello schema, in modo da poter distribuire facilmente gli aggiornamenti, con le versioni dello schema aggiornate automaticamente (e downgrade se necessario).(Non sono sicuro, ma probabilmente funziona anche con model-first)

Aggiornamento

La domanda richiede anche un confronto tra code-first e modello EDMX/db-first.Code-first può essere utilizzato anche per entrambi questi approcci:

Utilizzo innanzitutto il database EF per fornire maggiore flessibilità e controllo sulla configurazione del database.

All'inizio il codice EF e il modello sembravano interessanti all'inizio e forniscono l'indipendenza del database, tuttavia in questo modo non è possibile specificare quelle che considero informazioni di configurazione del database molto basilari e comuni.Ad esempio, indici di tabella, metadati di sicurezza o una chiave primaria contenente più di una colonna.Trovo di voler utilizzare queste e altre funzionalità comuni del database e quindi devo comunque eseguire direttamente alcune configurazioni del database.

Trovo che le classi POCO predefinite generate prima durante il DB siano molto pulite, tuttavia mancano gli attributi di annotazione dei dati molto utili o le mappature alle procedure memorizzate.Ho utilizzato i modelli T4 per superare alcune di queste limitazioni.I modelli T4 sono fantastici, soprattutto se combinati con i tuoi metadati e classi parziali.

Il primo modello sembra avere molto potenziale, ma mi dà molti bug durante il refactoring dello schema di database complesso.Non so perché.

Lavorare con modelli di grandi dimensioni era molto lento prima dell'SP1 (non l'ho provato dopo l'SP1, ma si dice che ora sia un gioco da ragazzi).

Progetto ancora prima le mie tabelle, poi uno strumento interno genera i POCO per me, quindi mi prende l'onere di svolgere attività ripetitive per ogni oggetto poco.

quando utilizzi sistemi di controllo del codice sorgente, puoi facilmente seguire la cronologia dei tuoi POCO, non è così facile con il codice generato dal designer.

Ho una base per il mio POCO, il che rende molte cose abbastanza facili.

Ho visualizzazioni per tutte le mie tabelle, ciascuna visualizzazione di base fornisce informazioni di base per le mie chiavi esterne e i miei POCO di visualizzazione derivano dalle mie classi POCO, il che è di nuovo abbastanza utile.

E infine non mi piacciono i designer.

Esempio di primo approccio al database:

Senza scrivere alcun codice:Primo approccio al database ASP.NET MVC/MVC3/Prima base al database

E penso che sia migliore di altri approcci perché la perdita di dati è minore con questo approccio.

IMHO penso che tutti i modelli abbiano un ottimo posto, ma il problema che ho con il primo approccio del modello è che in molte grandi aziende con DBA che controllano i database non si ottiene la flessibilità di creare applicazioni senza utilizzare i primi approcci al database.Ho lavorato su molti progetti e quando si è trattato di implementarli volevano il pieno controllo.

Quindi, per quanto io sia d'accordo con tutte le possibili variazioni: Code First, Model First, Database first, devi considerare l'ambiente di produzione reale.Quindi, se il tuo sistema sarà un'applicazione con una base di utenti di grandi dimensioni con molti utenti e DBA che gestiscono lo spettacolo, potresti considerare la prima opzione del database solo la mia opinione.

Penso che uno dei vantaggi del codice sia che puoi eseguire il backup di tutte le modifiche apportate a un sistema di controllo della versione come Git.Poiché tutte le tabelle e le relazioni sono archiviate in quelle che sono essenzialmente solo classi, puoi tornare indietro nel tempo e vedere quale era prima la struttura del tuo database.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top