Perché dovrei usare Entity Framework codefirst se non può essere utilizzato in produzione in modo sicuro e cose come gli indici non possono essere descritte

Question

Sto appena iniziando un progetto web estremamente grande, e cerco davvero di fare tutto bene.

miei strumenti che utilizzano finora sono

• ASP.NET MVC 3
• Entity Framework 4.3
• Ninject 3

Tutto sta andando bene, ma mi sto trovando alcuni cose con Entity Framework CodeFirst un po 'approssimativo.

Ad esempio, ho dovuto utilizzare http://codefirstmembership.codeplex.com/ per configurare le informazioni sull'appartenenza come parte della prima configurazione del codice. Questo sembra un po 'ropey di dover usare qualcosa di terze parti di questo. Ovviamente dovrei avere 1337 abbastanza da "tirare il mio" ma non voglio mordermi troppo dal cominciare. L'esecuzione di aspnet_regsql è orribile e si perderà con ogni aggiornamento di db. Comunque, ha funzionato tutto con la libreria di cui sopra e non è poi così male. L'impalcatura sembra essersi rotta comunque.

Al di là di tutto questo, ora sembra che questa roba diventerà probamatica quando sono in esecuzione nell'ambiente live. Qualsiasi modifica dello schema che intendo fare tra dev db e live db dovrà essere gestita manualmente con script comunque, quindi a quel punto non perderò prima il punto del codice?

Ho lavorato con Google App Engine per l'ultimo anno e speravo che il codice prima funzionasse essenzialmente allo stesso modo? Cioè, apportare modifiche e modificare i dati in tempo reale. Ora suppongo, a causa di non aver fatto un severo refactoring nel motore delle app, che fondamentalmente non danneggi nulla nella produzione. Quindi non potresti mai rinominare una tabella con AppEngine. Creerebbe sempre un nuovo tavolo e lascerà quello vecchio. Dovresti eseguire manualmente il porting dei dati.

Quindi ora sto pensando. Perché non basta andare prima al Database? Ho lavorato con linq2sql per 3 anni e mi sono sentito molto a mio agio con il primo db. Anche se TBH il mio controllo della sorgente db è stato un po 'scarso. Quindi speravo che il codice per prima cosa avrebbe rinforzato quella situazione per migliorarla, ma in realtà mi fa sentire che dovrei andare prima su DB, e solo essere severo nel tenerlo sotto controllo.

Gradirei davvero qualche idea su questo tipo di situazione, e anche, come si confronta con l'uso di Nhibinate?

Answer 1

Lo scenario di aggiornamento che stai descrivendo viene aggiunto in EF-Migrations. La versione go-live di questo è già disponibile e dovrebbe essere presto disponibile come versione di rilascio ufficialmente supportata.

Partenza: https://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx?Redirected=true

Partenza: http://coding.abel.nu/tag/ef-migrations/

Answer 2

Solo il mio prendere su questo ...

Non è necessario fare una scelta per il bene -

è possibile utilizzare Seed, inizializzatore personalizzato (e migrazioni mano nella mano - con le migrazioni è possibile cambiarle manualmente, ad esempio aggiungere indici lì ecc. - anche se con attenzione), per "iniettare" l'SQL raw (e la maggior parte delle esigenze c potrebbe essere coperto da quello). Per quanto ne so, potresti eseguire un inizializzatore di un file batch personalizzato (ma non ho provato, anche se non vedo perché no).Le migrazioni avvengono tramite PS, quindi immagino ci sia spazio per integrare anche da quel lato.

Si può usare al prototipo cose e di avvio - ottenere il vostro # struttura C in atto e in sincronia veloce - poi modellarlo in seguito - o una volta l'uso fisso un po 'di utilizzare initializer esistente', che non fa nulla dal codice e spostare tutto al lato Db e al tuo DBA.

IMO, puoi andare 'molto lontano' in questo senso, prima di dover effettivamente disattivare CF e lavorare solo da Db.

Per database di grandi dimensioni o ambienti aziendali, non è sicuramente lo strumento giusto per il lavoro.

penso che sia ora al sicuro per la produzione - ma dipende da ciò che si considera cassaforte, alcune cose ...

Inoltre, EF/CF è andato un lungo cammino fin dagli inizi davvero - ho usato fin dall'inizio - e inizialmente aveva grossi problemi. Le ultime versioni ora sono piuttosto solide su tutti i lati, quindi ci sto arrivando.

... al ribasso - Avevo elaborato alcuni scenari piuttosto complessi con il primo approccio al codice (EF e altro). Tuttavia, poche cose mi trattenne con EF (in cima a quello che lei ha citato) ...

supporto UDF, vista (con LINQ - come se non sei usare LINQ uno dei grandi 'pro' is Gone) - che dovrebbe apparire in EF 5.0 (non ho controllato ma è quello che stanno promettendo) - per quanto riguarda gli scenari più complessi è necessario ottimizzare sul lato SQL (o essere in grado di eseguire query personalizzate sul retro e poi mappa indietro, cioè più flessibilità su quel lato). Quindi è una cosa promettente se arriva (anche se non sarà perfetto mi aspetto). (sul lato positivo, è possibile eseguire query personalizzate e quindi mappare i propri oggetti, ma funziona in quel modo e non è possibile fare tutto in modo limitato)

Prestazioni con query e di nuovo per utenti più esigenti scenari di dovere: quello era il mio problema principale. Questo è anche promesso di venire meglio in EF 5.0 - quindi aspettare e vedere.

Detto questo -
il mio preferito è un codice personalizzato o open source prima come soluzione, ORM - dove è possibile avere più cose sotto controllo. Avere ancora molti provider di supporto, ecc. È ciò che rende le implementazioni "ufficiali" o MS più redditizie a lungo termine.

speranza che questo aiuta qualsiasi