Entity Framework è la strada da seguire per la nostra situazione?

Per quanto riguarda il controllo delle versioni, ti dirò che hai già questo problema in una forma diversa, anche se potresti non saperlo. Hai un database, ma hai più progetti che accedono ai dati, correggi? In sostanza, ciò che sta accadendo ora è che dal momento che tu stai utilizzando (probabilmente) SQL per accedere al tuo database in ciascuna delle tue applicazioni, il tuo progetto si compila comunque, indipendentemente dalle modifiche apportate al database. Qualsiasi vero cambiamento si verifica in fase di esecuzione.

Aggiungendo un modello di dati di entità, si sposta semplicemente questa interruzione nella propria applicazione a una che avviene in fase di compilazione. Credo che la mia domanda a te sia "come stai modificando la versione del tuo database?" Ti suggerirei di creare un modello di dati a singola entità, inserirlo in un assieme e apportarvi modifiche quando apporti modifiche al tuo database. Utilizzare la ramificazione e l'unione nel provider di controllo del codice sorgente per gestire il modo in cui queste modifiche si verificano effettivamente nel flusso di lavoro di sviluppo. Le versioni più recenti di Entity Framework sono molto meglio al giorno d'oggi per la gestione delle unioni rispetto a prima.

La mia esperienza è: è l'inferno sulla terra.

Abbiamo un grande prodotto principale che ha molti moduli aggiunti. Un determinato cliente avrà un core più uno o più moduli, e ogni cliente avrà un insieme diverso di moduli per qualsiasi altro. I moduli possono apportare modifiche allo schema del DB, in genere alle proprie tabelle, ma a volte aggiungere colonne alle tabelle principali.

In precedenza questo era facile, apporta le modifiche a sql e spediscile insieme alle istruzioni di installazione per ciascun modulo. Nessun problema (a meno che, ovviamente, non sia stato installato correttamente, ma questo è un problema con qualsiasi cosa).

Quando ci siamo trasferiti su EF, non è stato divertente. Innanzitutto, se apporti modifiche al tuo DB, cambi di conseguenza il tuo EF locale. Dovrai quindi ricostruire tutti i moduli e il core che usano quell'assemblaggio EF - o ottieni errori o, peggio, non riesce a caricare completamente un modulo. (ok, puoi usare GAC e i file dei criteri, ma si sommano rapidamente e avere molte delle stesse DLL nel GAC smette di funzionare, abbiamo trovato)

Quando si tratta di eseguire il test, ora è necessario creare un assieme EF che visualizzi il DB utilizzato dal cliente e ricostruire tutti i componenti, poiché si dispone di un sistema di controllo delle versioni, oppure nessuno di essi verrà caricato.

Quindi siamo passati dalla scrittura di un file di testo con istruzioni sql che sono state eseguite in qualunque DB, per farlo, oltre ad aggiornare molte diverse DLL EF e assicurandoci di averle installate correttamente, oltre a ricostruire molti dei nostri moduli tutto il tempo. Forse avremmo potuto farlo meglio con le sub-EF dll, ma quella principale è di diversi Mb quindi non avevamo voglia di gestirne molti contemporaneamente su ogni sito del cliente.

I risparmi potrebbero essere presenti in un'applicazione siloed (si intende monolitica), ma è comunque necessario gestire le ricostruzioni mentre si modifica lo schema DB (o si finisce per distribuire molte e numerose DLL EF). Potrei essere tentato di farlo di nuovo e cercare di farlo bene, ma penso che il vecchio modo fosse così semplice e infallibile che non riesco a capire perché mi preoccuperei. Avere LINQ è bello, ma scrivere vecchio sql non ha richiesto esattamente tutto il giorno per scrivere.