Wizards of Smart

I recently came upon a question in the Domain Driven Design Yahoo! Groups asking whether or not the presentation layer should interact directly with repositories or through a method on the entity (domain model). Having just finished Nilsson’s Applying Domain Driven Design Patterns and (finally) getting my head around LINQ to SQL on my current project, I decided to weigh in on the matter.

As always, it depends. You can indeed allow the presentation layer to use the repository directly, just as you can allow the presentation layer to use a factory to create your entities. Your current implementation is something I started off with when I started trying to do DDD, and follows more of the Active Record pattern, as mentioned by another responder, thought Active Record, by definition, matches the database table field for field.

You have several options:

1. Use your current approach. You’ll probably need to merge your repository and entity by using static methods and properties, though, which can make it messy, and I wouldn’t recommend it. That’s why I stopped using this approach, anyway.
2. Add a validation mechanism to your repository to validate your entities or, if your entities validate themselves, report the entities’ validation before you save.
3. If you really like the Save method on your entity and you use .NET or a dynamic language (not sure about other platforms), you can use extension methods to “add” a Save method that wraps a call to your repository. This is really option 2 with some syntactic sugar.
4. BEST PRACTICE (?): Use a Unit of Work, such as LINQ to SQL’s DataContext, Entity Framework’s ObjectContext, or NHibernate’s / SubSonic 3′s ISession to manage transactions and repsoitories, then call SubmitChanges() through the unit of work.

The Unit of Work pattern can be a little hard to understand at first, but it is quite powerful and great for managing rollbacks (which are extremely difficult if you always wrap your unit of work/repositories in the entity methods).

For reference, try these links:
http://iridescence.no/post/ASPNET-MVC-DataContext-and-The-Unit-of-Work-Pattern.aspx
http://www.west-wind.com/weblog/posts/246222.aspx

For keeping LINQ to SQL and Entity Framework persistence ignorant (PI), see:
http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!397.entry
http://code.msdn.microsoft.com/EFPocoAdapter

Our efforts to create a library for building enterprise-level LOB has led us to the Domain Model, Data Mapper, Repository, Unit of Work and Lazy Load patterns, just like everybody else. I just got my copy of Nilsson’s Applying Domain-Driven Design and Patterns and enjoy it very much. I believe Rob Conery commented on the pattern of patterns approach that defines Domain-Driven Design. That statement, while a bit incomplete, appears to hold true.

Aside from well-documented pitfalls, domain-driven design appears quite fresh and appealing, at least to me. Nevertheless, I ran into several hurdles while trying to implement the Unit of Work and Repository patterns. In particular, where do I add the Data Mapper? I’ve puzzled over this the last few days without any good answers.

This evening as we were walking out the door, JB and I decided we’d finally look into Expressions and building our own IQueryable implementation so that we could lazy load our mapped domain models. Lo and behold, I think this answers my other questions, as well, as building the query expression also allows us to map to the data provider, no matter what that may be, including Entity Framework or LINQ to SQL Expression trees.

Implementing IQueryable also allows us to catch each object as it is pulled through the iterator and tag it for change tracking. Now many reading this post will probably be thinking that this sounds like a lot of work—and I’m sure it is—and that these benefits were supposed to be delivered through Entity Framework, LINQ to SQL, etc. Well, you are right, but due to the lack of interfaces and current limitations, these may not always be the best options.

I’ve just started learning this myself, so I can only point you to the how, not the how hard. Check out the LINQ: Building an IQueryable Provider Series. As I progress, you can be I’ll be commenting on the ease or difficulty of building a custom IQueryable provider. Several others appear to have gone this route, so it can’t be a completely worthless pursuit (see SubSonic and IQToolkit).

Anyone else taken the plunge? What were your experiences?