2011-11-07 4 views
6

Attualmente sto imparando l'approccio di progettazione basato sul dominio allo sviluppo e l'utilizzo del .NET Domain Driven Design con il libro C# di Tim McCarthy come guida.Domain Driven Design ed Entity Framework 4.1 (code-first)

Il libro è davvero utile ma sto diventando un po 'scollato quando si tratta di utilizzare il framework entità, in particolare l'approccio code-first disponibile in 4.1.

In base all'esempio riportato nel libro, l'approccio dell'architettura a livelli dovrebbe significare che il livello infrastruttura non può vedere il modello/dominio.

Quindi qual è l'approccio migliore per mappare il mio dominio poco nelle classi di contesto db che (presumo) dovrebbe stare nel livello infrastruttura, senza violare l'approccio a più livelli?

C'è una buona possibilità che mi sto sbagliando completamente nel mio modo di pensare quindi per favore fammelo sapere mentre sto ancora imparando!

Molte grazie :)

Adam

+1

Se si utilizza EF Code-First, i POCO sono in realtà il proprio modello di dominio – Didaxis

+0

Sì, questo è ciò che ho capito, ma come si fa a fare riferimento a questi oggetti tra i livelli, in particolare l'infrastruttura al dominio/modello? – adam

+0

I miei modelli si trovano in una libreria di classi e la libreria di business fa riferimento a tale DLL. Consiglierei di leggere alcuni articoli sui modelli di unità di lavoro e deposito online, funzionano bene con POCO. Qui: http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application – AFD

risposta

7

Ebbene oggi la maggior parte di ORM, come EF 4.1 e NHibernate (fluente Nhibenrate addon) può descrivere mappature da POCO al contesto Db attraverso classi di mappatura. Queste classi di mappatura dovrebbero essere collocate al meglio in un progetto di database infrastrutturale, magari insieme a classi specifiche di sessioni ORM.

Quindi le classi di dominio POCO devono essere inserite in un progetto di dominio che non deve avere riferimenti ad altri componenti o progetti. MA il progetto di database infrastrutturale dovrebbe fare riferimento al dominio in modo che le classi di mappatura possano descrivere in che modo i POCO dovrebbero essere caricati da uno stato persistente.

Utilizzare molta iniezione di dipendenza insieme a una buona e solida struttura IoC (Castello di Windsor ...). Questo ti aiuterà a sciogliere un po 'le cose. È meglio dipendere da un'astrazione/interfaccia piuttosto che da un'implementazione.

Ecco le basi http://www.infoq.com/articles/ddd-in-practice

ma buona cosa avete deciso di andare per il codice Primo approccio. Consiglio vivamente questo approccio se ne hai la possibilità. Ma a volte quando i vecchi sistemi legacy interferiscono, le cose non sono così facili.

+0

Grazie Magnus, questo è l'approccio che ho preso: l'assembly separato che fa riferimento sia al dominio che ai livelli dell'infrastruttura! Avendo giocato ieri con esso, il code-first sembra una bella funzionalità di EF! – adam

+0

Buona fortuna adam. Sentiti libero di chiedere o discutere altro problema DDD direttamente a me. Sono sempre interessante come le persone vedono i problemi in modi diversi ... –

+0

Grazie Magnus - Ho qualche altra domanda, qual è il modo migliore per contattarti? – adam