Entity Framework 6 Architettura database First e Onion

Question

Sto utilizzando il database Entity Framework 6. Sto convertendo il progetto per implementare l'architettura della cipolla per passare a una migliore separazione delle preoccupazioni. Ho letto molti articoli e ho guardato molti video ma ho riscontrato alcuni problemi nel decidere la struttura della mia soluzione.

Ho 4 progetti: Core, Infrastruttura, Web & Test.

Da quanto ho appreso, il file .edmx deve essere inserito nella cartella "Infrastruttura". Tuttavia, ho anche letto sull'utilizzo dei modelli di Repository e Unit of Work per aiutare nel disaccoppiamento EF e nell'utilizzo dell'iniezione di dipendenza.

Con questo detto:

• Avrò per creare interfacce repository sotto NUCLEO per tutte le entità nel mio modello? Se è così, come si potrebbe mantenere questo su un enorme database? Ho esaminato l'automapper, ma ho riscontrato problemi con la presentazione di IEnumererables e IQueryables, ma c'è un'estensione disponibile che deve sfruttare questo. Posso provare questo percorso più a fondo, ma voglio prima ascoltarlo.

• In alternativa, dovrei lasciare il mio edmx in Infrastructure e spostare i file T4 .tt per le mie entità su CORE? Questo presenta un accoppiamento stretto o una buona soluzione?

• Un'interfaccia di repository generica funziona bene con il suggerimento fornito? O forse EF6 risolve già il problema del deposito e dei modelli UoW?

Grazie per aver guardato la mia domanda e per favore presentare eventuali risposte alternative pure.

Ho trovato un post simile qui che non è stato risposto: EF6 and Onion architecture - database first and without Repository pattern

Answer 1

Database primo non esclude completamente l'architettura Cipolla (aka Porti e adattatori o esagonale Architettura, in modo da se vedete i riferimenti a quelli che' è la stessa cosa), ma è certamente più difficile. Onion Architecture e la separazione delle preoccupazioni permette di adattarsi molto bene con un design basato sul dominio (penso che tu abbia citato su twitter che avevi già visto some of my videos on this subject on Pluralsight).

Si deve assolutamente evitare di inserire EDMX nei progetti Core o Web: l'infrastruttura è il posto giusto. A quel punto, con il database-first, avrai delle entità EF in Infrastructure. Tu vuoi che i tuoi oggetti business/entità di dominio vivano in Core, però. A quel punto hai fondamentalmente due opzioni se vuoi continuare su questo percorso:

1) Passa prima dal database al codice (magari usando uno strumento) in modo che tu possa avere entità POCO in Core.

2) Mappare avanti e indietro tra le entità dell'infrastruttura e gli oggetti principali, magari utilizzando qualcosa come AutoMapper. Prima delle entità POCO supportate da EF questo era l'approccio che seguivo quando lo usavo, e scrivo repository che si occupavano solo di oggetti Core ma che internamente sarebbero mappati su entità specifiche di EF.

Per quanto riguarda le domande su repository e unità di lavoro, è già stato scritto molto su questo, su SO e altrove. Si può certamente usare un'implementazione generica del repository per consentire un facile accesso CRUD a un ampio insieme di entità, e sembra che potrebbe essere un modo rapido per andare avanti nello scenario.Tuttavia, la mia raccomandazione generale è quella di evitare repository generici come strumenti per accedere ai propri oggetti business e utilizzare invece Aggregates (vedere DDD o il mio corso DDD con Julie Lerman su Pluralsight) con un repository concreto per radice aggregata. È anche possibile separare le entità di business complesse dalle operazioni CRUD e seguire solo l'approccio Aggregate laddove è giustificato. Il vantaggio derivante da questo approccio consiste nel limitare il modo in cui gli oggetti sono accessibili e ottenere vantaggi simili a una facciata sul set (grande) di database.

Non pensare di poter avere solo un dbcontext per applicazione. Sembra che tu stia evolvendo questo progetto nel tempo, non iniziando con un'applicazione green field. A tal fine, potresti conservare il tuo file .edmx e forse un repository generico ai fini del CRUD, ma poi creare un nuovo codice prima dbcontext per una serie specifica di operazioni che garantiscano entità POCO, separazione delle preoccupazioni, maggiore testabilità, ecc. Nel tempo , è possibile spostare la maggior parte del codice essenziale per utilizzare questo, mantenendo comunque il dbcontext esistente in modo da non perdere e la funzionalità corrente.

Answer 2

Utilizzo il framework Entity 6.1 nel mio progetto DDD. Il codice funziona molto bene se vuoi fare architettura di cipolla.

Nel mio progetto abbiamo completamente isolato il repository dal modello di dominio. Il servizio applicativo è ciò che utilizza il repository per caricare gli aggregati e persistere gli aggregati nel database. Quindi, non ci sono interfacce di repository nel dominio (core).

La seconda opzione di utilizzare T4 per generare POCO in un assieme separato è una buona idea. Per favore ricorda che il tuo modello di dominio (core) dovrebbe essere persistente-ignorante.

Mentre il repository generico è valido per l'imposizione di operazioni a livello di aggregazione, preferisco utilizzare un repository specifico in più, semplicemente perché non tutti gli aggregati avranno bisogno di tutti quelli generic repository operations.

http://codingcraft.wordpress.com/