One Real World NHibernate vs. TableAdapter comparison

If you're new to the hibernate vs. old-school data access debate, you hear arguments like:

• "hibernate is slow and too hard for regular programmers!"
• "manual data access is tedious and non-productive!"
• "hibernate is a software Viet Nam!"
• "manual data access is people!"
  

Frankly, most java folks have been sick of this argument long before NHibernate came around. There's truth and FUD on both sides of the argument, but how many people have the time or inclination to compare the two styles of implementation in a real project? (I'd love to hear your real stories - not just "my brother's cousin said that their team totally failed/succeeded on this one big project".)

On a recent small .NET project for a client, I started out creating the implementation using NHibernate, but was then told after my first draft that they'd prefer to stay away from third party tools due to their concerns over maintainability (that's a whole 'nother discussion in itself). So I got to rewrite the exact same functionality using Table Adapters. Since my data access was behind interfaces, it was a great way to see some metrics comparing the two implementations.

The most interesting metric: lines of code

• NHibernate DAO: 29
• Table Adapter DAO: 534

This was for a DAO with about 30 attributes in its main table, and about 6 one-to-many tables. Of course there were differences in the supporting code, but they were fairly equal in size (actually, NHibernate's supporting code was much smaller too). The biggest "I-can't-believe-Scott-Gu-tells-people-to-do-this" bloat in the TableAdapter code was things like this:
If Not row.IsFooFlagNull Then
ep.FooFlag = row.FooFlag
End If

And all the other garbage syntax that TableAdapters require, including the already-more-verbose manual one-to-many code that has to be written. Yuck - at least that's my opinion for this particular application of the technology.

Not that I'm a Hibernate bigot - I have seen those scenarios where Hibernate simply falls down when dealing with massive amounts of objects, and I'll be the first to say "stored proc?" (Well, maybe not the first.) But for those that are dealing with .NET versions that don't support ORM yet, you really should consider NHibernate for your project.