Are you using NHibernate for a project with an outdated database that is not partially controlled?

Question

For me, the answer for the time being: No, I would use iBatis because NHibernate is a pain when the database model and object model are not synchronized. If I do not have full control over the database, I get a lot of work.

Why am I asking?

Well, first of all: I have never used NHibernate. I just know it from the surface. I read about the benefits of iBatis for legacy databases.

Secondly: Recently I had a discussion with someone who worked with Hibernate (jep, without "N" before Hibernate). He told me that the ORM framework is currently quite advanced and supports Hibernate. Since I was not interested in NHibernate, I did not keep track of recent events.

Maybe it’s time for me to reconsider my answer or not?

Answer 1

iBatis is certainly easy to map objects to legacy database systems.

More recently, NHibernate 1.2 and 2.0 have a feature set that can make you rethink iBatis.

NHibernate works with composite keys, which are often found in old databases, they are not always pleasant to work with, but support is there for that.

NHibernate can use stored procedures for CRUD operations for entities as well as database representations.

Collections can be custom stored procedures or SQL queries. Collections can use the property-ref attribute if the foreign key relationship does not map directly to the primary key on the other hand.

Some of these functions may get away from nhibernate's performance / power, i.e. Lazy Loading does not work with the ref function (in general?), But in most cases there are reasons for this.

Other points: (which are not actually related to your old database, but can still help in choosing a technology)

The Nhibernate community looks much richer than iBatis. I am on both lists, and NHibernate's support volume is quite large compared to the iBatis group. Therefore, support should be simpler.

The number of contributors / third-party tools for NHibernate is also growing. Things like NHibernate Profiler, Nhibernate Query Analyzer, NHibernate Contrib, Fluent NHibernate to name a few.

Perhaps you can expand on the benefits you think iBatis currently has. NHibernate is certainly quite active lately and has received many new features, many of which help to obsolete / difficult to modify schemes.

And to answer the question, yes, we use NHibernate with outdated databases that have terrible relationships, compound keys, broken relationships. We also have a little code based on iBatis. We no longer write iBatis code though.

Answer 2

Yes, consider NHibernate. This is the gold standard for a reason. I heard that iBATIS supports crazy matching capabilities, but with NHibernate IUserType you can match everything, even really weird columns.

@Ahmad, the whole point of ORM is to prevent a tight connection between your objects and your circuit. If you have this problem, you are doing it wrong.

In addition, there are many options with NHibernate for user queries, formula properties, and stored procedures. HQL is extremely efficient, and the criteria are flexible.

I think that you will do your customers a bad service, if you, at least, do not sleep NHibernate.

Answer 3

I am using nHibernate in an existing application. I use it for all new developments, I have no intention of porting existing material, or there simply is no good reason, but it works great for new things in the project.

If you intend to port the code, you should be able to modify the database to better fit your domain model, without much influence (depending on how vulnerable your database is, i.e. who gets it). However, changing the domain model will affect the application.