that’s a good approach, i usually try to do the same, although my base repository isn’t abstract.

In situations where you want to take advantage of NHibernate’s MultiCriteria, it’s hard not to leak the DetachedCriteria though. In those cases, i really can’t be bothered with providing an abstraction that doesn’t really provide a true benefit.

public class OrderRepository : Repository[Order] {…}

where the [ ] are actually supposed to angle-brackets

Sorry for the multi-posts, took me a bit to realize what was going on (which is odd since my own blog is also using wordpress and I have the same issue(s)~!)

public class OrderRepository : Repository {…}

(I forgot the ‘of T’ part of the derivation statement~!)

1) create a Repository class much as you have outlined

2) we make ours abstract so that consumers MUST derive from it in order to use it as in…

3) public class OrderRepository : Repository {…}

4) within the OrderRepository class, we create methods like OrderRepository.GetOrdersSince(datetime orderDate) {…} that *internally* make use of the base Repository methods you suggest (Find, FindOne, etc. and can properly leverate the ICriteria API

5) callers of the data access methods then follow a pattern like…

OrderRespository orderRepository = new OrderRepository();
orderRepository.GetOrdersSince(‘1/1/2007′);

…and consuming code NEVER explicity does…

Repository orderRepository = new Repository();

…and in fact cannot since Repository is intentionally abstract. This way we get the goodness of the generics-enabled repository approch where the guts of the messy NHib-related code resides but the fact that NHib is in there somewhere isn’t exposed to callers of the data-access-methods.

Don’t get me wrong, I wouldn’t choose an ORM over another just because of Linq support … it’s a matter of common sense.

As for the business decision, i would much rather go with an ORM because of the qualities that it has instead of simply going with an ORM because another candidate doesn’t support LINQ yet. LINQ is nice, but it is not that important. Even though LINQ is supposed to be a unified syntax and should in theory require less training, i don’t really see that happening. Each ORM and each LINQ provider will have its own little quirks. The syntax might be the same, but the behavior might be somewhat different from provider to provider. The results should be the same, but a fast performing statement with one provider might be horrible with another. Merely going for LINQ because of the unified querying syntax is a bit shortsighted

This confirms the idea of ‘write a strongly-typed repository only if you really need it’.

What we are talking about here is also a business decision, not just a technical one: if you write repositories strongly-coupled with NHibernate, it means the developers that will work on your app must know how to use NHibernate’s HQL / Criteria API … the time you gain by ‘writing less code’, you might loose it in training, debug, support. Also, as you say, you’re not gonna change of ORM in the middle of a project, or between phases / releases … so, you might want to choose an ORM that provides you with the safest future evolution path. And I think that today, starting a project with an ORM that doesn’t support Linq is a little bit ‘annoying’, to say the least.

It also depends on the size of your project, you might not want to add an extra layer of abstraction for small projects … but you would probably consider it on ‘hundreds of entities & thousands of business rules’ projects.

Concerning the ProductsRepository, sorry but I still call it a Dao. ;o) In essence, what you’re doing is moving your stored procedures out of the database. Why do I need to give a name (=> method of your strongly-typed repository) to every possible query I need in the application ?

In you don’t mind your ORM to leak in your repository interface, a nice alternative is to have a generic repository that accept ORM-specific query criterion.
Your business components can then query directly on your generic repository (Ayende has a nice post called ‘Querying is a business concern’). If you want to re-use some of your queries, you might want to check the Specification pattern. The public API of your Business layer will be fine as long as it doesn’t expose any ORM-specific type. This also implies that you will have to component-ize your business layer, which is a source of many other design questions. lol

The generic repository of Rhino.Commons is actually designed that way … you can derive from it, but you should only do so if you really need it (very complex queries that you want to encapsulate) … there is no point of creating a lot of methods for simple queries. For most cases, you can just use the generic repository and simply pass it your query criterion.

Regarding your earlier comment that repositories should provide a layer of abstraction between the business logic and the data access logic: in theory, you are correct. Practically speaking though, what’s the point in providing another layer of abstraction for NHibernate’s ICriteria? It’s not like you’re just gonna switch ORM’s in the middle of a project. And since you’d have to write more code to provide the abstraction you should think about the added value of that code. Is there really a benefit? Wouldn’t it be easier to just extend this repository class with specific versions for each entity that needs a repository?

for instance, you could easily provide a ProductsRepository class which extends this repository class. In the derived repository you could provide clean methods like FindProductByName or whatever that only take the required parameters, and the implementation of that method would only need to construct the criteria and pass it on the base repository implementation. Expose only the clean methods through an IProductsRepository interface, have your business code communicate only with the repository through that interface and voila, you’re done without needing to do unnecessary work to achieve purely theoretical ‘correctness’ :p

NHibernate is leaking in your repository implementation … a repository is supposed to give a layer of abstraction between your business logic and your data access logic. This is not the case here. What you call repository in this case is nothing more than a Dao.

I’ve written some post about a generic Linq-friendly repository (inspired by several open source projects and blog posts):
http://blog.yoot.be/post/Domain-Driven-Design-with-Linq–ORM2c-Part-2.aspx

Who wants to use HQL or NHibernate criteria when Linq is around ? ;o)

http://www.hibernate.org/361.html#A7

According to that, DB2 UDB is indeed supported. However, i would recommend that you definitely experiment with it to make sure it indeed does everything you need it to before you actually commit to using it in a real world project. Better safe than sorry