Monolithic or partitioned domain?

Topics: Prism v1, Prism v2 - WPF 3.5
Jul 31, 2009 at 12:51 PM

I am just getting started with Prism, after building traditional apps structured around domain-driven design. I have typically put my domain model and data-access layer in separate projects. The Prism documentation suggests that I should partition my model and data-access, and then incorporate the relevant portions into each module.

What is considered best practice?

-- Treat a domain model and data-access as cross-cutting concerns, and keep them in their own loosely-coupled projects?

-- Partition them and incorporate them into the app's modules?

If there is no clear best practice, what would you see as the pros and cons of each approach? Or, if the answer is "It depends", on what sorts of things would it depend? Thanks for your help.

David Veeneman
Foresight Systems

Jul 31, 2009 at 2:18 PM

Since PRISM is a multi-targeting framework it is my practice to keep my implementation of the data access layer (DAL) interface(s) as "their own loosely-coupled projects".   This way each platform can configure it's own implementation of the DAL interface.  For example, in an open source application I am creating (to be activated/released late August) I have a WPF, Silverlight, RIA and WinForms applications sharing the same codebase (using project linking); I have PrismContrib.xxxxx projects (where xxxxx is WPF, Silverlight and WinForms) that manage the differences for the PRISM framework.

The RIA application implements IDataService using an .NET RIA Service (blogged about here).  The WPF, Silverlight and WinForm applications currently implement stubbed in data (work in progress).   With the RIA proof of concept out of the way I'll now create a WCF Async service that can be shared by the WPF, Silverlight and WinForm applications.  

Within this context it would not be practical to have each data layer incorporated into the module (not extensible nor reusable).  I do however have a Service within the module which acts more as a business logic layer - it is shared across each platform and dependency injection dictates which DAL implementation will be used.

Side note:  coding in this manner will minimize refactoring when you are ready to implement the Managed Extensibility Framework (MEF).



Jul 31, 2009 at 11:23 PM

Thanks—very helpful!