I'm going to agree with Gunnar on the Learning Curve issue. While I can understand that it's tough to get into a code base where the concept count is high, I think that it's frequently taken too far. I get daily exposure to this mindset and I can tell you that the results typically aren't what you expect. My opinion is that NHibernate has documentation that's widely available and a community like this one. A home spun abstraction will likely have little documentation and a much smaller group of people that know it.
Of course, you can go crazy the other way too and make a single, flat project that does everything ;) I think the key is to find a good balance for your specific situation. We started with our "repositories" specifically to limit what kinds of queries the UI could run, but after using them for awhile, they proved to be too inflexible and we were frequently adding special case methods to avoid N+1's and other issues. On Apr 26, 6:56 pm, Gunnar Liljas <[email protected]> wrote: > Yes, ensuring proper access to aggregate roots is a valid case for > abstracting out NH, but other than that.... > > 1) Learning curve > It may be a valid concern in some teams, but generally I find it > disheartening to see how much time and effort is spent trying to create > "APIs for dummies". We consciously build obstacles, as if we don't even > trust ourselves to do the right thing. > > 2) Testing > Yes, it's easy to mock a repository and it neatly reduces the scope of the > test. But, testing with an in-memory database is pretty darn sweet too. It > may violate a couple of testing dogmas, but I really don't care. It's > productive and more accurate, given its quasi integration test nature. > > 3) Restriction > "Reduction of complexity is a crucial aspect of good software engineering > and API and domain design" is mostly true, but "reduction of complexity > which also results in reduction of productivity and quality" is often the > result. > > /G > > 2011/4/26 Rory Plaire <[email protected]> > > > > > > > > > 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. -- 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.
