A word about the repository as abstraction. I do like abstracting data access but I believe the repository pattern is overrated. I rather prefer to have IQuerySomething/QuerySomething, an specific interface and class to represent query. Fabio did a great job explaining this aproach: http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html This allows you to use the full power (all queries mechanisms) of nhibernate in only one place, test it against a database and then mock it when testing dependants.
Just to be clear, it doesn't mean that I am really concerned about having NHibernate as reference in the domain (or in the presenters as Ayende described). But,I am much more concerned in things like testability, SRP, and so on. EQO is the standard way of doing things in .Net (not only data access speaking). When you find something complex to model/test/etc you take this out of the outer logic, and create a new separated artifact for doing the thing, so you can easily test it and mock it when testing dependants. 2011/4/27 Matan Goldschmiedt <[email protected]> > 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. > > -- 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.
