Dovresti riutilizzare un Entity Framework EDMX tra più soluzioni?

5

Al momento abbiamo 1 EDMX gigante per il nostro database aziendale. Esso, insieme a tutti i POCO generati, si trova in un progetto separato (lo chiameremo progetto EDMX) che inseriamo in ogni soluzione che utilizza il principale Banca dati. In altre parole, qualsiasi nuova applicazione che sviluppiamo utilizza questo stesso progetto EDMX. Naturalmente, il progetto EDMX richiede un riferimento a Entity Framework. Ma anche i progetti principali per ogni applicazione. Pertanto, una determinata soluzione ha 2 riferimenti di Entity Framework separati, che potrebbero finire per essere versioni completamente differenti.

Ho ereditato questa configurazione e ora ho l'opportunità di apportare grandi cambiamenti. Ho il sospetto che non dovremmo usare questo EDMX per soluzioni multiple, ma non sono sicuro al 100%.

Domande

  1. È possibile che due versioni diverse di Entity Framework in una determinata soluzione causino problemi? Sembra che lo sarebbe, e di certo non vogliamo limitare le nostre nuove applicazioni a una vecchia versione di EF per lavorare con il progetto EDMX, che a sua volta funziona con soluzioni precedenti.
  2. Ci sono altri motivi per cui sarebbe male?


Nota: ho letto domande simili sull'utilizzo di 1 EDMX all'interno della stessa soluzione (rispetto alla suddivisione in base allo schema, ecc.), Ma la mia domanda è diversa perché sto parlando dell'utilizzo di 1 EDMX per tutte le soluzioni .


EDIT 16/10/14: Quindi ho praticamente risposto alla mia prima domanda. Almeno tra Entity Framework 5 e Entity Framework 6, effettivamente causa problemi. Quando il mio progetto EDMX ha installato EF5 e aggiorno il mio progetto principale all'EF6, molte delle mie query LINQ (all'interno del progetto principale, che fa riferimento alle classi generate-POCO all'interno del progetto EDMX) si interrompono. A quanto ho capito, questo ha qualcosa a che fare con i cambiamenti nello spazio dei nomi. Se c'è una soluzione alternativa per far funzionare le due versioni, non l'ho trovata.

La mia seconda domanda ha ancora bisogno di risposta, tuttavia. Ci sono altri motivi per cui sarebbe male fare, oltre alle versioni in conflitto di Entity Framework? Dal punto di vista del design, avere 1 EDMX ha senso? potrebbe essere facile da aggiornare (se una tabella di database viene utilizzata da più progetti cambia, c'è 1 posto per aggiornarlo). L'ovvio problema è che i nuovi progetti sono limitati a una vecchia versione EF finché tutti gli altri progetti non vengono aggiornati. Altri problemi che potrebbero emergere? Sto solo cercando una direzione.


EDIT 10/17/14 Ho accettato una risposta, ma i commenti sull'utilizzo dell'EDMX da parte della vostra azienda / vostra azienda sarebbero comunque utili / aggiornati. Più prospettiva, meglio è.

    
posta EF0 10.10.2014 - 20:14
fonte

1 risposta

2

Dipende.

La cosa principale su cui mi concentrerei è "non ripeterti". Se si dispone di un gruppo di applicazioni che utilizzano le stesse entità, non ha senso dedicare un sacco di tempo e sforzi e quindi mantenere la stessa cosa più e più volte. Peggio ancora, può diventare un mal di testa per mantenerli tutti corretti e sincronizzati.

D'altra parte, se hai davvero una serie di schemi diversi che vivono nello stesso database (e non interagiscono), allora può avere senso avere più file EDMX indipendenti.

Ho visto entrambi i modi e hanno funzionato abbastanza bene nei loro ambienti. Ma vista la difficoltà di Entity Framework nel giocare con gli altri, mi farebbe un errore nel mettere tutto un database in un singolo progetto, dato che è meno faticoso "usare solo una parte di esso" piuttosto che "farlo funzionare anche con quelle altre cose" dovrebbe la mia ipotesi è sbagliata sull'uso futuro.

    
risposta data 16.10.2014 - 18:41
fonte

Leggi altre domande sui tag