C# nhibernate mulitier architecture

Question

I need some advice: I would like do decouple nHibernate dependencies in the Presentation and Business Logic layers in order to have only the Data Access Logic layer referencing the nHibernate DLLs.

I only see solutions using SessionHelper/SessionManager objects and all being created used at the top layer. I beleave a better solution must exist.

What design pattern should I follow ? Can I wncapsulate the session (manager, helper, etc) in the repository pattern and easily change the ORM without forcing changes at the Business Logic layer ?

A code sample would be appreciated. Thanks in advance.

"easily change the ORM?" you could only use the least common denominator between all ORMS you might want to use. You will suffer from performance problems because you can't use a lot of features to enhance that and you will have leaky abstraction. — Firo
This question comes up a lot and the general answer is: don't do it. There are very few cases where being able to swap out the ORM is worth the significant trade-offs required. It's difficult to "hide" the ORM without completely neutering it. — Michael Maddox
Hi @MichaelMaddox: In theory I do not want to switch ORMs since the Client does not pay that kind of investment. My goal is to be able to implement base/generic classes (to apply in all my projects) and that allow me to hide what I do not want to be seen (i.e. dependencies to the ORM). I would like to encapsulate the nhibernate session, EF objectcontext, etc. How would you implement such a class ? — Joao

David DV David DV · Accepted Answer · 2012-03-13T09:40:48

Here is a nice presentation about nHibernate Worst Practices

What you are asking is the first Worst Practice, so be sure to check it out

You should check out the presenters nice blog which reviews these types of "architectures"

"What design pattern should I follow" Be sure to always use the common-sense design pattern and YAGNI :)

C# nhibernate mulitier architecture

1 Answers