How can I solve this NHibernate Querying in an n-tier architecture?

Question

I\'ve hit a wall with trying to decouple NHibernate from my services layer. My architecture looks like this:

web -> services -> repositories -> nhiber

Answer 1

abstracting away the ORM will:

• bring a lot of work of redefining it's API
• make it impossible to optimise/batch database access
• make it a lot harder to understand what queries are executed
• will lead to tons of SELECT N+1

and all for very little value: the vague option to exchange the ORM framework which will most probably have a lot of other problems

• missing features
• subtle difference in implementation
• learning curve

Update: experience

I was once involved in implementing a new provider of an existing DAL abstraction. It ended up performing badly, introduced a lot of bugs, Errorhandling was a mess and sometimes used stale data because the application assumed the default implementation. Reasons:

• Caching does not know context
• Cacheimlementation had different semantics
• batching APIs too different to be abstracted
• Errors are specific to implementation (e.g. FileNotFound -> FilesearchDialog is uselesss for a tcp/ip based databases)
• Error recovery is different (each implementation has it's own set of errors it can recover from)
• locking mechanism was different
• no consistent change event in SQL-Databases
• nested transactions
• default implementation bleeded in Model classes
• reimplementing all abstracted Queryies was a lot of work and introduced a lot of copy paste bugs
• querying without explicitly stating the order will return different ordered results in different implementations

It took a lot of refactoring of the application:

• strip out features only one implementation provides
• Cachemanagement for each implementation
• problem of Identity of Wrappers because of transient data
• implement Queries over two datastores very hard

Additional points:

• Migration of Data through the abstract DAL is slow as hell
• implementing yet another implementation will never occur because of the above stated problems it is too expensive (In the mentioned scenario we began to slowly reimplement the whole project)
• it was extreme difficult to implement the correct semantics of the DAL API because there is no context of use in the pure API

Porting (of business tasks) would have been a lot less painfull IMO as we did that for a few because of performance.

Update2: experience2: RoadBlocks while trying to port from NHibernate to EntityFramework (impl with NH but couldn't with EF 4 in reasonable time)

• nested Transactions
• Enum support
• references with compositeId (how to get rid of referenceIds)
• references in Components
• read batching (Futures) which is handy for page + count in one go
• mapping CultureInfo (IUserType support)

Answer 2

Thank you for the responses! I understand what you are saying, but these answers do not solve my problem. Because of the state of the system I'm writing, I am unable to change my architecture. Instead, I am just going to keep all of my sql/hql/criteria api queries inside of the repository layer instead of trying to expose some sort of a complex query class to my services. This approach should work just fine. For my next architectural approach though, I will consider the points made in the other answers.