NHibernate for Enterprise applications?

Question

I know that NHibernate works well for projects where you are starting with a fresh database and building from the ground up. In my experience, however, that is not usually the case for enterprise applications. More often than not, integrating of legacy data from other databases is a major part of a new app.

Is NHibernate going to be more trouble than it is worth as an ORM when you are going to be dealing with legacy database structures over which you have no control?

I know that arguments for building data services and loose coupling, and that will come in time. But, for now, if I have to use data from 15 tables in two different existing databases in addition to storing my own data for the app, is using NHibernate (or, more broadly, any type of model-driven ORM tool) going to drive me crazy?

Answer 1

By default, the NHibernate sessions are configured to connect to a single database. It is possible to setup your Data Access Layer to use different NHibernate sessions to connect to different databases. If you'd like it to automagically mesh the data between the two databases into a single object, however, you'll likely be disappointed. The nice thing is NHibernate works well with database views, so if you need to do something complex, you can always write a view that is updatable via database triggers.

As far as the database design goes, NHibernate has a wide variety of structures to allow legacy databases to function properly, such as multi-column primary keys, and other "bad-design" oddities.

I would recommend it.

Answer 2

It depends only on how much are you comfortable with NHibernate.

Answer 3

IT depends, I had some questions about it here as well, and still didn't get a good answer. Things you should care about:

a. using NH with layered app might kill NH session special abilities - like lazy loading. WCF can't pass "half initialized"

b. session cache might be useless without good notification infrastructure, and not available at the client side.

c. you need to study HQL....

sometimes ORM is much slower / inefficient than doing the work yourself.

so I guess you need to test it a little on a small scale project, see what it is worth for you and only than try it in enterprise project.

From performance point of view, you can get much better performance doing it on your own....

Here Is my own question on the subject... no good answer yet to come...

Answer 4

One of the main advantages of using an ORM like nHibernate is that it large decouples your application's business objects from the database. Does the customer table include address information but you want a Customer object to contain an Address class? NHibernate can do that quickly and easily in XML.

One of the main points of using an ORM is that you are free to design the objects in your system without database concerns and then map the attributes of those objects to their representations in the database. So you can follow an Object Driven Design rather than a Data Driven Design approach.

ORMs are designed to be used with legacy databases. They might have their downsides but they are, in my experience, overwhelmingly advantageous.

Answer 5

I think it depends on how you need to work with the legacy database.

Is it just for reading? I'd hand write some data access code for that instead of dealing with multiple session-factories. But maybe you need to create complex dynamic queries, then it might be worth the trouble.