Sql Server Data Tools & Entity Framework - c'è qualche sinergia qui?

Uscendo da un progetto usando Linq2Sql, sospetto che il prossimo (più grande) potrebbe spingermi tra le braccia di Entity Framework. Ho fatto qualche lettura sull'argomento, ma ciò che non sono riuscito a trovare è una storia coerente su come SQL Server Data Tools e Entity Framework dovrebbero / potrebbero / potrebbero essere usati insieme.

• Sono stati concepiti totalmente separatamente, e usarli insieme sta accarezzando nel modo sbagliato?
• Sono in qualche modo totalmente ortogonali e mi manca il punto?

Alcuni motivi per cui penso che potrei desiderare entrambi:

• SSDT è ottimo per avere 'compilato' (controllato) e facilmente sql e schema facilmente versionabili
• Ma la storia di "migrazione / aggiornamento" di SSDT non è convincente (per me): "Aggiorna qualcosa" funziona bene per lo schema, ma non c'è modo (AFAIK) che possa mai funzionare per i dati.
• D'altra parte, non ho provato la migrazione EF per sapere se presenta problemi simili, ma i bit Su / Giù sembrano abbastanza utili.

Lasciatemi mettere in un altro punto di vista. La manutenzione del database di Entity Framework è assolutamente inutile in qualsiasi progetto di database aziendale o di grandi dimensioni.

I problemi sono:

• Aggiornamenti automatici dello schema. Questo non è assolutamente quello che voglio perché viola totalmente i fondamenti della manutenzione del database. I problemi sono: (a) qualcuno che esegue una versione più recente aggiorna il database invece di riscontrare un problema e (b) gli aggiornamenti sono pianificati con il dba che normalmente esegue un backup PRIMA. Pertanto, gli aggiornamenti automatici sono inutili.

• La creazione di database funziona solo su casi limite sostanzialmente degeneri. Non provare nemmeno a utilizzare le funzionalità di database avanzate, indipendentemente da quale. Esempio di server SQL: campi inclusi negli indici, filtri sugli indici, partizionamento, compressione, regole di convalida per i campi.

• Migrazione: presuppone nuovamente casi limite degenerati: nessuna trasformazione dei dati o aggiornamento in più passaggi facilmente. Esempio: la tabella X ha un campo "utente" storico che registra l'utente che fa qualcosa. La nuova configurazione ha una tabella utente, quindi è necessario creare la tabella utente, quindi creare gli utenti, quindi creare il campo di riferimento utente nella tabella x, quindi aggiornarlo con l'utente dalla tabella utente, quindi eliminare il campo utente.

L'unico modo sensato per gestire questi scenari sono gli script di generazione e migrazione e il controllo delle versioni corretto.

Ora, SSDT - che è un ottimo strumento per il versioning di una versione specifica del database molto meglio di Entity Framework perché funziona davvero. Come in: registra tutte le funzionalità. Su nessuno dei database che possiedo, potrei praticamente usare prima il codice - perché almeno abbiamo sempre filtrato gli indici;) EF non mi porterebbe nemmeno al 10% di ciò di cui ho bisogno.

Il nostro approccio è:

• Progettare il database nel database, quindi eseguire la sincronizzazione su un modulo SSDT che viene archiviato. La sincronizzazione dello schema consente agli sviluppatori di aggiornare rapidamente la loro versione. C'è sempre un database master autorevole con la versione corrente da qualche parte (su un server speciale), quindi abbiamo una versione di riferimento su cui lavorare.

• Genera script delta in base alle necessità per le versioni anch'esse con versione e dispongono di un meccanismo utile per distribuirle in un database.

Esiste più di un modo per utilizzare EF con un database SQL Server.

1. Primo codice ... Scrivi le classi e EF genera le tabelle associate
2. Prima il database ... Si progettano le tabelle e EF genera le classi.

EF non farà necessariamente tutto il lavoro per te. EF ti porterà dall'80 al 95 percento lì. L'altro 5-20 percento del tuo sforzo di sviluppo del database sarà integrato con ottimizzazioni come viste e procedure memorizzate.

Quindi no, non sono ortogonali. Ma dovrai decidere quale sarà la tua strategia di progettazione complessiva, quindi fare affidamento su strumenti come SSDT per aiutarti a ottimizzare quelle parti in cui EF produce risultati non ideali.