A repository doesn't always ease the code's testing or readability. I would try to give a good example if there wasn't already a good one here: http://ayende.com/Blog/archive/2011/02/23/flatten-your-architecture-simplicity-as-a-core-value.aspx
Fabio - I didn't quite understand your opinion - why shouldn't there be a fluent configuration to NH Search? Also, if I get you right, you think attributes are best for configuration and the domain should reference NHibernate? On Apr 27, 2:56 am, 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. -- -- Make sure to check out my blog at www.codecovered.net -- 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.
