Entity Framework Code First è un po 'insignificante / inutile nella produzione e qual è una buona strategia EF per la produzione?

Ho programmato di recente con Entity Framework 4.1 Code First e lo adoro per lo sviluppo, ma con solo un piano finale e un elenco di funzionalità in rapida evoluzione, modifico costantemente la Classe / Database per soddisfare le esigenze delle applicazioni.

In fase di sviluppo, non ci sono dati live e posso facilmente cancellare l'intero database in modo che venga ricreato con il nuovo schema, ovviamente, quando è attivo - questo è molto male!

Le uniche soluzioni che posso vedere sono o eliminare la tabella dei metadati e mantenere manualmente il database sincronizzato o sostanzialmente rilasciare e ridimensionare.

Personalmente preferisco il primo metodo poiché penso che sarà molto più semplice aggiungere una colonna / tabella piuttosto che ricreare e migrare i dati, ma, a meno che non mi sia perso qualcosa, questo si sta completamente allontanando da Code First.

Quindi la domanda è davvero: Code First riguarda solo lo sviluppo iniziale e qual è una buona strategia per la gestione di EF per un ambiente di produzione?

frameworks entity-framework

— wilhil
fonte

Ho intenzione di chiedere questo per alcuni giorni, non ero sicuro che fosse meglio qui o su Stack Overflow ...

— Wilil

Risposte:

La mia opinione è che la creazione automatica del database di code first è solo per lo sviluppo. Ho risposto a domande simili su Stack Overflow in cui ho descritto sia come aggiornare il database sia perché la funzionalità automatica non è buona nella produzione:

L'aggiornamento del database è un'attività semi-manuale. Non ci dovrebbe essere nessuna magia automatica non testata dietro - inoltre EF 4.1 attualmente non ha tale magia disponibile (c'è solo una presentazione sulle funzionalità su cui il team ADO.NET sta lavorando).

Puoi anche controllare questa domanda per capire meglio come vengono aggiornati i siti web.

— Ladislav Mrnka
fonte

Ciao di nuovo! -Sei veloce sulle domande EF! :) ... Non so dove sarei senza di te!

— Wilil

Pochi mesi dopo e il mio programma è piuttosto finito ... Lo segnerò come risposta, ma mi chiedevo se qualcosa è cambiato / ci sono risorse che possono aiutare?

— Wilhil,

È stata rilasciata la prima anteprima pubblica di "Migrations". blogs.msdn.com/b/adonet/archive/2011/07/27/…

— Ladislav Mrnka

Grazie, guardandolo adesso! Mi è piaciuto molto sviluppare con Code First, ma sono così nervoso / preoccupato di cambiare in seguito!

— Wilhil,

Come gestite i casi in cui StoredProcs o Views vengono creati direttamente nel DB per altri scopi, ad esempio i report non utilizzati dall'applicazione. Dovremmo prima sapere quali SP sono interessati da una modifica dello schema nel codice.

— softveda,

Mantenere gli script di aggiornamento .

Nel database stesso, mantenere una tabella in cui è conservato un record con la versione dello schema.

All'avvio dell'applicazione, rileva la versione rispetto alla versione che dovrebbe essere utilizzata dai file binari. Se differisce, esegue (o chiede all'utente) gli script di aggiornamento.

Non dimenticare di eseguire prima il backup del database.

Passaggio successivo: si viene licenziati;) Gli aggiornamenti del database non dovrebbero essere eseguiti automaticamente prima senza un backup - e possibilmente nei periodi di inattività, non quando ONE USER esegue una versione più recente. Il tuo approccio è perfetto - per chiudere implementazioni più grandi con tonnellate di errori.

— TomTom

@ TomTom: dipende. Da diversi anni eseguiamo perfettamente un'applicazione DB che fa esattamente questo: modifiche automatiche allo schema per una nuova versione, eseguite dall'applicazione quando rileva una versione troppo vecchia. I backup vengono eseguiti quotidianamente e manteniamo tutte le modifiche allo schema compatibili con le versioni precedenti (aggiungendo solo campi e tabelle, non eliminandone mai). Concordo sul fatto che le misure menzionate sono importanti quando le modifiche non sono compatibili con le versioni precedenti e non è possibile garantire l'aggiornamento simultaneo di tutte le applicazioni client (ad esempio, per i database di grandi aziende).

— Doc Brown,

In cima se le modifiche non sono banali. Prova a cambiare un campo in una tabella da 2 TB (e sì, mi occupo di questo - e non è nemmeno un data warehoue). Ti sei messo in uno scenario in cui stai accumulando debiti tecnici perché puoi sempre AGGIUNGERE campi, mai ripulire.

— TomTom,

La domanda è in qualche modo imperfetta in quanto crea connessioni tra il modello di programmazione e l'ambiente di runtime dove non ce n'è.

Il codice innanzitutto è principalmente un driver di velocità di sviluppo e non è realmente collegato al sistema di runtime.

In produzione si avrà correttamente un'impostazione di configurazione che nega al runtime la possibilità di cancellare / aggiornare il modello db.

— casper
fonte