There are 3 reasons we abstract NH out of the domain layer: 1) Learning curve. Since NH is abstracted out, there is a layer which a developer's knowledge can stop at. Since many of the developers on the team are just learning the .Net platform, this is a significant advantage, since NHibernate is another complex library on top of already needing to learn WPF, Castle, MVVM, LINQ and Moq. Giving the developers an IRepository interface with accessor methods and Eric Evan's DDD book is a great way to limit exposure to complexity as well as help teach the pragmatics of DDD.
2) Testing. As has been mentioned, and in conjunction with #1, mocking a repository with a specific query method is very easy and facilitates writing good and numerous tests. Intentions are also very clear. While NH veterans have no trouble reading Criteria method chains or even HQL strings to get the intention, those just learning all of this are overwhelmed. 3) Restriction. One of the complaints about not using the Repository pattern on top of NH is that it restricts the power of NHibernate. This can be a good thing, however. Reduction of complexity is a crucial aspect of good software engineering and API and domain design. If my Repository has methods which limit and describe how it can be queried, then the roles of the various aggregate roots in the domain become more apparent via the domain model itself. Of course there are numerous corner cases and times where we want to query the repository dynamically, but so far exposing a "Query" method which returns an IQueryable<T> has sufficed us, even when querying by custom types (thanks to the extensible LINQ provider). While all of this has a cost - generally duplicating a lot of the API that NHibernate already provides, it has been worthwhile due to the reduced complexity and restricted domain language in learning, testing and communicating the intention of the system. -rory On Tue, Apr 26, 2011 at 2:03 PM, Fabio Maulo <[email protected]> wrote: > No, it shouldn't. > Those attributes should be transformed in a API as we done in NHV and NHE > (Envers). > > > On Mon, Apr 25, 2011 at 5:20 PM, Matan Goldschmiedt <[email protected]>wrote: > >> Hi, >> >> I'd like to use NHibernate.Search via Nuget, I thought I'd start by >> attributing my entities using the NHibernate.Search.Attributes >> namespace. Problem is that the NH Search package depends on NH which >> means that my domain class library would reference NHibernate. >> >> Up until now I managed to avoid that since I figured that my domain >> shouldn't be aware of NHibernate at all, is it a lost fight, or am I >> better adding a manual reference only to NHibernate Spatial? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> > > > -- > Fabio Maulo > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
