Comments on The Untitled Blog: An Opinion on Repository

You're not the first person to say that. :) http:...

2009-07-07T07:35:51.406-04:00

You're not the first person to say that. :)

http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx

I still like the repository, but maybe I'm just used to it. My repository class mostly just calls into NHibernate's ISession, but it's allowed me to abstract some stuff away (like setting FlushMode on the session, hiding NHibernate's query stuff inside methods with nice names, etc.).

It's not like it's a lot more work to have a repository in there. It's one file that I wrote one time and I pretty much never change it, but it allows me the flexibility to override the default behavior if I ever need to.

Will I ever need to? I might not. But I think having the extensibility point is worth it especially since it didn't really cost me anything to put it in.

@Jon So why not just have your service layer just...

2009-07-06T22:34:36.404-04:00

@Jon

So why not just have your service layer just take a dependency on NHibernate's ISession, or Linq To SQL's DataContext? It doesn't seem like the repository really buys you anything...other than adding a layer of indirection so swapping out ORM implementations can be achieved.

The way I see it, the single responsibility of the...

2009-07-06T11:05:14.365-04:00

The way I see it, the single responsibility of the Repository is to perform operations on a data store (CRUD operations using an ORM, calling stored procs, etc.) The repository itself should not have any business logic in it -- that goes in a domain service.

So in your example, I would change IOrderRepository to something like IOrderService, IGetOrderService, or IGetPendingOrdersService (depending on how granualar you want to get with it). The domain service would not derive from IBaseRepository<T>, but would take an IBaseRepository<T> in as a constructor parameter so that it could perform the query.