LINQ and Domain Driven Design
As I’ve progressed with development of a website, I’ve increasingly come across problems with adapting LINQ with a Domain Driven Design. Here is what I have so far:
Data Context
Everything focuses around the data context. It is literally the glue that keeps things together. The data context encapsulates the Unit of Work and its associated object graph. Persisting and exposing this data context then becomes a real issue. What sort of scope should the data context have and what is the preferred method of persistence? Here are some of the requirements for the data context:
- Needs to persist across different pages
- Should not be persisted without clear purpose
- Should not be fully exposed
The persistence across different pages is fairly clear. One has to be able to carry out a transaction across multiple pages.
The data context also should not be persisted without clear purpose as it is designed to be used and disposed as needed. Making it a static variable only introduces more headaches as the data context is not thread-safe. By using a global data context, very soon your object graph will bloat. It is inevitable as you start accessing members which are lazy loaded.
The data context also should not be exposed to the UI layer, for example. Clear access to the data context will make the multi-tiered approach meaningless and it allows business logic to be introduced in the UI layer.
What works then?
I’ve thought about several solutions listed here:
- Create a data context for each transaction
- Create a data context for each business object
- Create a global data context
I will investigate this further as I have yet to come up with a good solution regarding the scope of the data context and its persistence.
Filed under: Team Foundation Server | 2 Comments
Alvin Yong's Techno Blog 
Hi Alvin, hope you are well.
I wanted to mention an alternative approach that might be viable. We are using NHibernate on my current project, which has a unit-of-work representation called ISession. We’ve managed to avoid having to maintain a particular ISession instance across http requests by instead using lightweight classes (rather than domain objects) to collect the data entered across several pages. Typically at the end of the process the lightweight objects are passed to factory or service methods that will construct the appropriate domain objects so you can then call into the necessary methods to apply business rules, etc. However I can definitely imagine scenarios where this approach is inappropriate. Anyway if you want to discuss this further please feel free to drop me an email.
Thanks for your feedback, Paul. I definitely will be contacting you regarding implementing NHibernate. I hope the new ADO.NET Entity Framework will offer better support for DDD. Expect an email soon!