Miroslav's Code Mind

I just had an interesting conversation with a friend of mine. He recently started to learn NHibernate, in fact we are working together on one application. 

Apparently, he got into an argument with his co-worker about NHibernate and O/RM in general. The co-worker of his is an experienced developer, the kind of people whose advice you would appreciate. And he had an advice. Don't use O/RM! It's slow, unnecessary complication which favors Java style of architecture. Oh, and it's extremely hard for debugging and maintenance! He used an O/RM in ONE project, and it's bad. Let's all avoid it.

Needles to say, but these arguments made my friend feel bad. Was it a bad decision to start learning NHibernate and to use it in an application?

The title of this post is a little harsh, but whenever I have an argument like this I always feel that the other person is trying to say to me that I'm an idiot. "Yes, you are!", you might said, "Why should it bother you. Don't take it to the heart." Well, what can I say ... It does bother me, so let me have my own arguments here.

1. It's slow - He's right. O/RM is slower than plain ADO.NET code. Several percents or tens of percents. Hell, it's another abstraction layer, it has to be. .NET Framework applications are slower than C++ ones, and C++ applications are slower than assembler ones. Does this mean that we should ditch .NET in favor of assembler? Maybe, for a tiny performance critical application or parts of code, but for an enterprise application...? The benefits of an O/RM outweighs the performance impact in most situations.
2. Unnecessary complication - I shouldn't even comment this, because I'm not sure what he meant or how was his application structured. In most cases I encountered, the developers (myself included) were more responsible for complicated applications than frameworks or tools. We often start using something just after looking at Hello World sample. Don't get me wrong, this can work, we learn as we go, but we should take a time to at least find and learn best practices.
   I still remember what came out of my first CSLA application. Boy, was it a mess.
   Or my first relational database application. It should have stored daily entries with details, plain master-detail case. I remember creating a table per day in code (Entry_10_05_99, Entry_10_06_99...), so each day details had it's own table. The case for The Daily WTF.
3. Java style architecture - WTF?!? What's wrong with Java? I've never used it professionally, but still appreciate all ideas borrowed from it in .NET Framework and third-party libraries and tools.
4. Hard for maintenance and debugging - Really? I wonder what O/RM has he been using. NHibernate uses log4net for logging and has option to log ALL generated SQL code. If that's not enough for you, it's Open Source, so you can attach the debugger to it and step thru the code if necessary.
   Hard to maintain? Let me tell you about the big enterprise application I had worked on several years ago and still have to maintain it... We did some bad design decisions and end up with business code in both .NET application and SQL Server stored procedures. Whenever we have to change something we make a change in stored procedure, than in .NET application, then deploy it, fix bugs, etc. Those changes in two places are rather tedious. Not to mention we don't have stored procedures under source control for obvious reasons. In other, NHibernate powered application, we have to only refactor and deploy. All our code is in one place, and under source control. That's why I favor "stored procedure"-less databases lately.
   And one more thing... Ever tried Unit / Integration Tests? You'll definitely have less bugs to cope with later on.

Final words. Don't let anyone kill your desire to learn new things just because he/she had tried it once and consider it bad. Try it for yourself, at least on a small test project. Learn more, don't limit yourself to one technology / framework / tool. Oh, and take your time to learn best practices :)

That's what ALT.NET tries to teach us.