DDD
In questi giorni sto utilizzando una funzionalità piuttosto interessante di NHibernate, ovvero la possibilità di mappare un domain model "dinamico" tramite dynamic-component.
Questa funzionalità permette di mappare in modo speciale alcune colonne di una tabella di un entità, infatti al posto di utilizzarle come singole proprietà vengono inserite in un dictionary (possono essere sia tipo semplici che vere e proprie entity).
Qui un link che mostra il funzionamento :
http://ayende.com/Blog/archive/2009/04/11/nhibernate-mapping-ltdynamic-componentgt.aspx
Qui invece un link che mostra come modificare la configurazione senza agire sul file di mapping, ma editando "on-the-fly" prima che la session-factory venga creata:
http://www.junasoftware.com/blog/custom-domain-using-nhibernate-dynamic-component.aspx
Ad un primo sguardo può sembrare un comportamento particolare, ma...
Navigando mi sono imbattuto in questo link : http://microsoftnlayerapp.codeplex.com/.
Riprendo direttamente dalla descrizione del progetto :
Domain Oriented N-Layered .NET 4.0 Sample App.
By Microsoft - Spain
Using .NET 4.0 C#, Entity Framework 4.0
Implementing typical DDD architecture & desing patterns
Una delle problematiche frequenti che ho incontrato nella stesura di domain model complessi è l'utilizzo di servizi di dominio all'interno di entità. Tra le varie possibilità ho trovato in rete e sperimentato tre diverse soluzioni:
Service locator statico : crea non poche problematiche (vedi unit test)..personalmente da evitare
Risoluzione delle dipendenze delle entità tramite DI : utilizzando per esempio NHibernate risulta piuttosto semplice risolvere la problematica usando un session interceptor
Double dispatch : risulta di facile implementazione e il codice è immediatamente...