Benjamin Day Consulting, Inc.: The Blog

So here's the deal. If the average guy off of the street can't maintain it, then what good is it? Isn't it all about creating and consuming things that the average joe programmer can consume? This is actually one of the few reasons why I think code generation is a good idea. It is a lot easier for the average person to pick up versus a whole new way of thinking with O/R mappings.

Dunno man...it's not that it's impossible to learn nhibernate...it's just that if you already
know ADO.NET it's a tough sell to bother.

On code generation though...how does code generation help the average developer with long term
maintenance problems?

-Ben

I started using NHibernate, and it saves me a lot of time. Plus the code is a lot cleaner to work with. ADO.Net is fine, but this is a mercedes compared to the standard DataSet methods.

Joe from around the corner won't understand this, but I think when you start working on bigger project, your no longer joe from around the corner :D

All I am going to say about hibernate is this:

There is a lot of FUD in the .NET world about it, because there have been a LOT of companies providing ORM-ish solutions to the same problem, and they saw what happened when Hibernate took over in the Java space. I empathize.

However, there *are* a lot of developers who are using NHibernate, and Spring.NET, and even Pythonnet and RDNZL and all kinds of other Secret Weapons to get their job done.

Why, if people are using them, don't we see more well-informed, obviously expert coders defending these technologies on the streets (blogs)? Why aren't these expert coders convincing everyone else that the disruptive technology is a good thing?

The answer: we have no reason to.

These things are our competitive advantage. It's ludicrous that anyone would have to defend Hibernate or NHibernate. There are already books on Hibernate in Java; Hibernate is going into WebSphere; NHibernate is ALREADY used in dozens of production applications to enormous effect. The idea that the .NET world is largely indifferent to the benefits of the best ORM tool on the planet doesn't spell "crisis", it spells "competitive advantage".

Thus, there is only one time when you'll see smart coders defend their competitive advantages in public, and that's when they're afraid that they might have to stop using them if they don't.

The reason to convince other people that NHibernate is useful -- assuming you do think it's a necessary and useful utility, assuming that you don't *need* to learn the technology because before Hibernate came along you were stuck building Hibernate-esque stuff that was less complete, and when you saw Hibernate you realized that it did exactly what you wanted it to do -- is when you're afraid that you may not be allowed to use NHibernate to get work done.

In other words, the only time you'll see people defending NHibernate from FUD is when they're

a) Just bored (me, right now) and expansive. And, really, I'm just explaining why you don't see people like me defending .NET more.
b) When that FUD endangers their ability to use NHibernate on their projects (see some of the posts by Frans Bouma, the maker of LBLLGenPro, on TheServerSide.NET -- and some of my responses ;)). If the FUD happens in a particularly visible place, you'll be amazed at the kind of rebuke it gets, from developers who are already using a particular technology and who are anxious to keep it from getting a bad name at a site that their coworkers or bosses might visit.

But in most cases, the kind of people who are likely to WANT to use NHibernate have enough weight or are given enough freedom at the places where we work that we are allowed to chose the appropriate technologies. Shoot, even languages if need be; I'm using Python, Ruby and Lisp to do development in .NET.

I've been using NHibernate as a secret weapon for a while now. Bofore I stumbled across I tried my hand at a number of other .NET ORM tools 4 a while (Neo, Objectz.NET, XPO..). The main things that made NHibernate that made it attractive to me were: a)It's unintrusive - no contorted base classes to inherit from. b)Mapping lives outside your code - Your app domain model remains intact. The only place in your code where your domain model needs to know about NHibernate is at the intersection of your business layer and persistence layer. c)Until you run into HQL, it's dirt easy.

Overall I'd definitely give it a big up. It's very mature, having done it's rounds on the java circit for a while already. Most other .NET ORM solutions are still very green and it shows after you look at NHibernate. I hope version 1 will be Whidbey ready. I can't hardly wait to see how generics will feature in future builds of NHibernate.

I am one of those few people who have worked extensively on C++, Java and .NET. I started using Hibernate on my J2EE applications about a couple of years back when it was still new on the market and people didn't quite appreciate Object-Relational tools. I think it will suffice to say that I used Hibernate for a very intensive application for a car rental company, for one of the leading telecom providers and for an online retailer. Never once did we face any problems with usability, ramp up, performance, etc.

In general, it is easier to approach Hibernate and NHibernate from the perspective of a software architect (which I have been for the past few years). If we take the simplistic looking comparison of NHibernate v/s ADO.NET, I see the following points emerging for out-of-the-box implementations of both:

- A database change will require a potential re-compilation of code if ADO.NET is used but only a change in a configuration file if NHibernate is used;
- Maintaining raw SQL queries is a pain;
- With NHibernate, maintaining object relationships is quick and out-of-the-box. With ADO.NET, all the code needs to be written;
- One can use out-of-the-box second-level caching with NHibernate, something that will need to be coded if ADO.NET were used.

All in all, it is worth using NHibernate for large applications with huge number of objects and complex relationships. One also gains in terms of automatic connection pooling, etc. which otherwise are a pain with ADO.NET.

NHibernate is a big honky load of crap in my opinion. Now, don't get me wrong. OR Mapping is a great way to code and I think it's definately the way to go so long as the OR Mapper doesn't get in the way. I recently found a new love of OR mappers when I learned Ruby on Rails. Their OR Mapper implies most of the configuration simply from a proper database naming convention. There's very little need if ever for manually configuring your mappings. Learning this and then learning nHibernate makes nHibernate look like a primative pile of poo. Not to mention the slickness of the ruby language allows for nifty dynamic helper functions. That way you rarely need to ever write a line of SQL or much less an SQL-like nHibernate query.

Thanks, Brian for the well thought out and considered comment. I think that we're probably talking about "apples and oranges" here since Ruby isn't currently a .NET language.

-Ben

sanx for post Benjamin

Another thing to consider is that you don't have to use HQL to do your queries. You can still write normal SQL or normal stored procs.

The time when you are most likely going to be doing big complicated queries is when you are doing reporting. You probably don't want to pull back a huge result set and convert it to objects just to bind it to a datagrid. It doesn't make sense. So there is no problem in this case just writing SQL and using ADO.NET directly.

NHibernate really gives you mileage when it comes time to do CRUD or change the schema. It is a pretty quick change in NHibernate instead of remembering to regenerate/rewrite all of those CRUD procedures.

It is cleaner that way which frees you up to move faster and have fewer dependencies on outside tools and vendors. Besides it is free - great price :) Also it is built on a very mature foundation (Hibernate has been around for years).

It has its weak points, but you can choose to use it for the part that is good at.

You don't have to learn HQL, you can also use the createCriteria() method and its related methods to dynamically construct the record selection criteria. For me, it's even easier than using SQL. Thanks to this dynamic criteria building, i have done moderately complex reports with NHibernate. Reports of 1000 records (of about 12 columns for each record) loaded in no time (less than 1sec for a local connection.)

Correction: They were reports outputing 5000 records (of 20 columns each record) in less than 1 second (including display in HTML)

Just because the majority of developers have not heard of a technology, that's no reason not to implement it.

Its this exact attitude that has got us .Netters so far behind the java guys in the first place.

I really cannot understand all the fuzz about how terribly hard it is to learn nHibernate, how it adds another thing to support and that is some sort of hightech tool used only by the true magicans. Really, are the most developers out there so plain stupid or they can only consume things packaged with letters MS? .NET API is huge in square compared to nhibernet, yet I don't see messages like "lets forget the .net as average joe cannot learn it. lets stick to ordinary asp".

Did someone just spam the comments?

Perhaps the larger issue is Microsoft's distaste for Open source. Look at what they are doing with their own testing - building their own Entity with ADO vNext, etc..

Why not use all that energy to encourage NUnit development, create NHibernate tools for VS.NET etc...

This is why .net developers only know about ADO.NET and Stored procedures - most are still wrapped up in the VB mess of 'easier means better' - which isn't true.

Just my 2 cents, but NHibernate has cut my dev time in half.. your code ends up being cleaner, simpler and I find you actually have to write less code over all... which is less code to test!

There's no way I'd ever develop without an OR Mapper again!

How to reports like CrystalReports by using NHibernate?

I use Hibernate for my own web application in Java and it worked great. I just started my first job ever as a .NET developer LAST WEEK and installed NHibernate today. It went right in with no problems, all the code is now very clean and it handles complex objects well. Also, I taught a VERY Junior developer (7 months total experience) how to use NHibernate while I was learning to use it in .NET. It's THAT simple. I cannot buy the argument that there is an issue with any developer who can't pick up NHibernate in just a couple of hours. I'm not a genius.

The thing about NHibernate, as it was said before, is that we are starting to think more conceptually. If someone said to me: "do you want your apps to add value to your client", I'd obviously agree. The thing is... if we are SO concerned about the data... how do we get into the client's business? in the end, the only reason for developing software, is adding value to our clients businesses.
Maybe I'm not as intelligent as others in this chat, but I can't manage to do everything at the same time.
I have my own architecture, my framework, call it like you want to. That let´s me think less about the coding and more about the business.
I know that the learning curve is higher, but doesn't something like this make you require less developers? let's face it. I'm in Argentina, and here, when a project ends, it has half the people who started it. It's better to have few, good, reliable developers than one hundred average joes, who will make your testing team be bigger.

Cheers, Alejo

Ben,

"And that's where I start to see a big downside to NHibernate. It's just another technology for someone to learn in order to get their work done."

The half of me that's just now learning to leverage NHibernate agrees with you. I already know how to write the SQL to get done what I need; obtaining *that* knowledge took time and effort, too!

The half of me that has had to maintain all the individual SQL queries (CRUD and much more) for an application...well, that half has to disagree with you. If I can substantially reduce maintenance costs by using NHibernate (even just for for basic CRUD and non-complex reporting tasks), the time and effort to learn it has paid for itself.

What I also wouldn't mind paying for is a GOOD book on best practices USING it, lol!

Jeff