ORM and NH for business people

Question

I have to prepare a case to convince managers to promote development using an ORM. I don't want to go into technical details in this case, the benefits have to be visible to business people.

I'm not quite happy with the arguments I've written down until now Are there any points I'm forgetting, both PRO and CONTRA?

The case I'm going to make will be in two points:

• Convince managers to use an ORM
• Convince managers to use NHibernate

The PRO's for ORM:

• Solves the impedence mismatch between a rich ecosystem of connected objects with behaviour and tablular lists of scalar values
• Higher productivity => reduced time writing tedious data access code lets you focus more on solving 'real' business issues
• Higher maintainability => reduced number of LOC == system is easier to understand (hmm... maybe...)
• Almost no performance hit when used right

The CONTRA's for ORM:

• O/R mapping tools do not perform well with bulk processing of data. Stored procedures may have better performance, but are not portable
• Heavy reliance on ORM software has been pointed to as a major factor in producing poorly designed databases

The PRO's for NH:

• Very mature produce
• Supports a lot of DB's => developers don't have to learn a new SQL dialect on every other project
• High mind-share amongst .net community leaders
• Many examples, articles, blog posts
• It's open source

The CONTRA's for NH:

• Not suited at all for batch processing
• No code generation or code designer => some people think this makes developers more productive
• Bad reputation due to lazy coding (== abuse of lazy loading)
• It's not from Microsoft
• It's open source => some companies just don't like that

Answer 1

Business people typically think in terms of cost and deliverables. Beyond that, most don't grasp or care about the technical reasons.

You already mentioned the higher productivity aspect.. try phrasing that as spending more time on business rules and less time on repetitive CRUD code.

I'd add, and highlight this:

• Lower development friction makes meeting deadlines easier
• Reduces cost of development in time spent working with the database
• Reduces cost of maintenance
• NHib is flexible; can handle object mapping automatically, and allow specific queries/stored procedures when needed

Also checkout Fluent NHibernate and Fluent Migrator.

Answer 2

You need to express it in terms of time and money - impact on development and maintenance time and impact on user time. ORM use is way too often the cause of a system that is strangling itself in poor performance (and which is now too far along the design path to change), so you need to address to the managers how you intend to avoid doing this. Frankly dev time and maintenance time are peanuts compared to wasted users time from bad implementation of an ORM. Yes it can be done right to avoid that but it usually is not. Often this is because the devs who use ORM don't understand databases and don't want to understand databases. ORM in the hands of a database expert, good thing, ORM in the hands of an application programmer who can't write basic SQL and who doesn't even understand joins, disaster waiting to happen.

Answer 3

When your manager decides which technology you have to use, your manager should be able to understand the technical reasons. Otherwise, he should trust the developers (they have the knowledge to make the decision) to decide. I can think of more useful things for a manager than making technical decisions he does not understand enough.

When your boss is like Dilberts pointy haired boss, I would go for the time and money saving argument (for every technical decision the manager wants to be involved in).

Answer 4

I'd actually like to rebuke some of the negative points.

O/R mapping tools do not perform well with bulk processing of data. Stored procedures may have better performance, but are not portable

NH has many optimizations for bulk data processing (batching and caching are the first that come to mind). And you can always add stored procedures for some cases, it's not an "all-or-nothing" proposal.

Heavy reliance on ORM software has been pointed to as a major factor in producing poorly designed databases

I've actually seen the opposite: supposedly optimized DB-first designs that fall apart when the real use cases are implemented. In any case, it's a developer failure; you can do poorly with or without an ORM

Not suited at all for batch processing

Absolutely not true. NH has many features specifically designed for batch processing, like Stateless Sessions. Of course it's hard to beat the performance of a SP running in the DB server, but apart from that, it'll usually do just as well as adhoc ADO.NET code.

No code generation or code designer

False. There are several products that provide that. Check http://nhforge.org/wikis/general/commercial-product-ecosystem.aspx

Bad reputation due to lazy coding

If you do SELECT * FROM TABLE it will perform badly too. I fail to see how NH is to blame.

It's not from Microsoft

Neither are Oracle, the iPod or BMWs, yet people use them

It's open source

There is commercial support available. And, unlike what happens with MS products, the support is provided by people who know the internals and can fix them in a few hours instead of a few years.

Answer 5

Take a look at this list of features of a real-world ORM. For any non-trivial project you will eventually end up using 80%+ of those features. So, either you can build those features yourself or you can use NHibernate. If you choose to build it yourself, be prepared to invest about $7.5M and 140 person years. Or you can just use NHibernate, save the money and effort, and benefit from the huge knowledge base available on the net, books, community, etc, and even use (if necessary) one of the high-quality commercial support providers available.

Answer 6

No code generation or code designer

As Diego pointed out, there are third party tools. However, I would like to stress that NOT having to use a designer is a strength of NHibernate. Designers typically don't scale in the following ways:

• What good is a design surface when an application has many, many entities? A visual designer just slows you down with noise at that point.
• Designers typically have issues with merging. They work great when only one developer needs to edit the model at a time. The more devs you have on a project, the more potential trouble there is for merging the designer files.