5

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?

9
  • 1
    Why don't you ask your Team Leader for his reasons?
    – Doc Brown
    Commented Mar 6, 2013 at 7:03
  • The reason is just to make the distinction... "ORM Tool should deal with objects"
    – Mithir
    Commented Mar 6, 2013 at 7:28
  • 1
    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
    Commented Mar 6, 2013 at 8:13
  • 1
    @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
    Commented Mar 6, 2013 at 8:51
  • 1
    @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
    Commented Mar 6, 2013 at 9:01

1 Answer 1

Reset to default
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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