Wagnerblog

Recently I was asked “ What technology do you recommend Linq or NHibernate” ?  My knee jerk reaction was “ It depends – potentially neither”. But that’s not good enough as an answer. The feeling that I owed a better explanation led me to this post.

Let’s start with some basics. Object Relational Modeling has been around for quite some time. The work by Dr. Raymond Chen has informed the design process of ORM systems for almost 30 years now. I posted 3 years ago that even Microsoft based its own decisions on the work of Dr. Chen.

Fast forward 3 years and it seems that many MS shops think that Business Objects, or ORM, in .NET 3.5 requires Linq.  Far from it. There are other, potentially more rewarding ways of doing ORM in .NET. Two prominent and mature alternatives on the market  are NHibernate and LLBLGen.

I should qualify one thing right up front: Linq tries to be more than an ORM tool. By definition Linq is “ a set of proprietary query operators that can be used to query, project and filter data in arrays, enumerable classes, XML (XLINQ), relational database, and third party data sources “

In short, Linq is more than a typical ORM mapper against a database. That is its strength and also potentially its downfall when compared to ORM mapper. While I personally think its great to use Linq to query things like Directory Structures or Strings, I also personally think that both NHibernate and LLBLGen are better at ORM – much the same way that SQL Server is better at managing data than say an XML document. Specifically, for example, Linq requires a developer to jump through some hoops when lazy loading an object graph. In addition the query tree expression generation code that Linq employes makes some odd decisions on occasion. That can lead to severely slow query performance.

As it stands, Linq is the 800Ib gorilla in the room because it originates with Microsoft. That means developers need to be able to work with it and the third party tool market has to cater to this by potentially adjusting its products to work with Linq.

Linq is extensible via a Provider pattern that implement the IQueryable<T> interface. A quick search of the Internet brought back examples of providers for CSV, OpenMapi and even Twitter. But writing a good Linq provider is no picnic at all. Many providers on the market today only cover a subset of the Linq spectrum. Writing a full-fledged Linq provider has taken one of the best programmers in the business almost a year and it is 1.2MB large. That should be a caveat for anyone contemplating that this is an easy task.

While Linq as a technology wants to be more than just an Object Relational Mapper for databases, both NHibernate and LLBLGen are exactly that and don’t try to be anything else. As a matter of fact, in the big scheme of things both tools are “closer to the metal” than Linq.  So much so that both tools offer a Linq provider that allows a developer to run Linq against NHibernate or Linq against LLBLGen. In that manner both tools broaden their market scope and build on the knowledge that developers have acquired when coming to the ORM space from MS centric projects. I am told by users who have tried the NHibernate Linq provider that it is still a bit immature at the time of this post. This just underscores the difficulty of writing a good one.

What then is the difference between NHibernate and LLBLGen? As far as I am concerned the differences fall into three large areas:   product philosophy, developer productivity and vendor quality / product maturity .

Product Philosophy:
NHibernate approaches the concept of building entities and mappers from the stand-point of designing business objects first, without any regard for databases or persistence structures at all.

LLBLGen, on the other hand, adheres closely to the work of Dr. Raymond Chen mentioned earlier. It builds entities on the basis of a database schema.

The tool of choice here really depends on how you approach the ORM space. Do you prefer to work with objects first and disregard persistence? For the time being NHibernate makes that easier than LLBLGen. I should point out that the next version of LLBLGen, due in a few months, has one incredible advantage over the competition – it will support Model-First development. By encompassing both design philosophies the LLBLGen designer tool – which by the way is the only fully functional designer tool in the ORM market – will cater to both camps. Essentially LLBLGen will allow you to work with NHibernate files, its own providers as well as Linq. Its a win win win situation.

Personally I have always worked with the db first approach.  I understand and sympathize with the object first approach. But the majority of my larger projects have existing databases. For instance I can’t very well insist that Chevron change its db structures, just to accommodate my ORM system.

LLBLGen makes work with existing data structures a breeze. Unlike NHibernate it supports multiple databases within one project, foreign key relations, prefetch paths and typed lists

As a side note, if you want to learn more about the object design first approach I recommend Jimmy Nilsson’s book “Applying Domain Driven Design Patterns”.  It’s a fantastic work on that subject.

Developer Productivity:
LLBLGen runs within a  separate development IDE (not within Visual Studio) and is by far the more productive tool. Turning a database into entities and using them in a project requires but a few clicks and option selections.

In NHibernate the developer is asked to hand code empty business objects (usually POCO’s) , then  manipulate an XML mapping file. I realize the typical argument here is to point out that this approach offers more control to the developer. Yes it does.  But the fine grained approach impacts productivity whenever changes need to made after the initial design. Especially with larger projects the need to work at a fine grained level can become cumbersome. After all the mapping files in NHibernate do not live in a vacuum.

A couple of years ago I had the pleasure of watching a longtime Hibernate architect become completely addicted to the productivity of LLBLGen. He literally was blown away by how much he could accomplish in very little time. In the end, the formerly dreaded change / update cycle became one of his biggest tools in being productive. My colleague took part in building one of the larger real estate loan processing engines in the US using Hibernate and Java – he knew those products inside out.

Vendor quality / Product maturity:
If you are faced with a tricky medical decision, whom would you trust more – a GP who deals with a variety of medical issues or a specialist that eats,  sleeps and breaths the specialty you need?  In other words if you can see the quality of the people whom you trust would that help in your decision process? It does in mine.

How smart are the people behind the tools you choose? In the case of LLBLGen and NHibernate I’d say the development is headed by a couple of programmers who are absolutely the best in the field (Ayende Rahien and Frans Bouma).  Contrast that to another ORM tool on the market – the MS Entity Framework and its problems over the past three years and you can see how essential the capabilities of the core devs in a tool like this really are.

Both LLBLGen and NHibernate are mature within the marketplace. NHibernate builds on its “big brother” Hibernate for Java.  While NHibernate is a failry mature open source project, LLBLGen is the most mature commercial tool of its kind in the .NET market.

Open Source projects are great in many ways – especially after they have settled down a little. But as a personal choice I will frequently pick a good commercial product over an open source one. There are several reasons for that. When your reputation is on the line with the projects you implement, its good to have a person who is directly responsible to you by the fact that you paid for their product. Granted with some vendors that’s a useless measuring stick but in a comparison between NHibernate and LLBLGen, I favor the latter because a very specific person is responsible for the performance of the product.

Overall there is a great sense of design and continuity in the product. I have used it since 2003 and I am here to tell you that in 6 years, through dozens of commercial projects for a raft of important customers – from Chevron to ITT Corp and Chrysler; from Lycos to Gameshow Network – accounting for several thousand man-hours of work it has never let me down.

Since this is not a product review I would urge you to visit the llblgen website and have a look. Features like visual inheritance definition, non-overwrite of custom code, support for all relationship types (1:1 ; 1:M ; M:1 and M:M) and much more can be reviewed there. And of course take a look at the NHibernate site as well. There is much to like in both tools. As it stands when someone asks me “Linq or NHibernate” I am very likely to answer “Neither my friend… but let me tell you about the tool that you should use ! ”

Update:  10-31-2009 – I just had to include Mohammed Meligy’s post because his experience parallels mine. Here is a link.