Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am new to ORM, and we started developing a new system using NHibernate as the ORM.

I think this question may refer to any ORM and any language/platform.

The Team Leader has said we should use NHibernate only when retrieving our domain data model objects, ie, not to use any of the built in NHibernate selection or aggregations that will retrieve single primitives or a list of primitives.

The reason behind it was that we need to make a distinction between classic ORM and other abilities, so that usual select and select max will use a "classic" DAL project.

I think this is not so good, because we break the data access to two, and what's wrong using NHibernate abilities which gets checked compile time?

Are there any reasons to making this distinction?

share|improve this question
Why don't you ask your Team Leader for his reasons? – Doc Brown Mar 6 '13 at 7:03
The reason is just to make the distinction... "ORM Tool should deal with objects" – Mithir Mar 6 '13 at 7:28
Best practice is to use only Hibernate to access your database. It is even heavily discouraged to use same database for different clients if you use Hibernate to access this DB. Hibernate loves caching stuff and having someone else change the data would break it. – Euphoric Mar 6 '13 at 8:13
@AakashM no, its more like if I want to get ALL product costs, but just the costs, so you can use an NHibernate projection with select, HQL etc. instead - we called the DAL with ADO.NET with a simple select statement. – Mithir Mar 6 '13 at 8:51
@Mithir I don't see a reason. NHibernate can create same SQL as you would do, while keeping things type-safe, in one place and focused on your domain. It will also cache this SQL so you don't have to worry about it being recreated all the time. – Euphoric Mar 6 '13 at 9:01
up vote 3 down vote accepted

You are going to have the most luck using the functionality baked into the ORM. NHibernate is incredibly flexible and knows how many different databases work. Using it will allow your database layer to be easily portable.

I would say to your team leader:

  • NHibernate produces optimised queries
  • NHibernate does lazy loading
  • Will allow portability across various database platforms
  • Supports its own, powerful, querying language.

Don't "worry" about data access code and leave that to the ORM. Focus on your business logic and problem domain.

EDIT: One thing I just thought of is that if you are manually loading objects you're likely to miss the best features of NHibernate because your objects are going to be detached.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.