OR Mappers for .Net, NHibernate vs LLBLGen In one of our previous projects we had to make a choice between the OR mappers NHibernate(1.x) and LLBLGen(2.5). It was a difficult decision and we ended up discussing various aspects. The decisive factors for the choice were mostly non-technical, like familiarity with the product, the clients willingness to pay/not to pay for a product, support requirements etc. Under such circumstances we may have to make a choice that we may not be quite happy with, as developers.

However a little time on the design and practices can help us to overcome some of the limitations. I would like to look at the differences/similarities and explain how some obvious design practices can solve some limitations.

1.What is?

NHibernate: OR Mapper. Works on plain objects.
NHibernate helps you to persist your domain objects.

LLBLGen: OR Mapper + Code generator.
Works on generated(from a database schema) entity classes.
LLBLGen helps you to deal with the data access tier.

2. Support: You know it :-). Its between free and paid software.

3. Documentation: There is quite a bit of documentation available for both LLBLGen and NHibenate. Also the source code is available for both.

4. Supported Databases: Both NHibernate and LLBLGen works for all major databases.

5. Mapping of objects to databases: NHibernate uses HBM(xml) files for database mappings while LLBLGen generates code using a visual OR mapping tool. While NHibernate XML mappings are not easily refactored the LLBLGens binary project file which makes it quite difficult to control the versions. This could be a serious limitation with big teams.


6. Database First or Domain Objetcs first: Its a matter of taste.

One argument is that, with LLBLGen typically the database is created first and the entity classes are generated. After any changes to the database the entity classes need to be generated again. Since the refactoring and IDE supports for the SQL is not as good as programming languages creating the database first may slow you down a bit.

Reallistically this problem(if at all) can be solved to some extent by creating a domain layer above the data acess layer and play around with your domain objects first and later think of the persistence.

7. Design style: In couple of projects using LLBLGen I have seen the entity classes are being passed between the client and server(across different layers). Using the entity classes as a replacement for your domain objects has some limitations.

The LLBLGen entity classes introduces coupling to the data access code and also has limitations to work with some frameworks (if I remember it correctly .. the LLBLGen documentation talks about this somewhere. eg: WCF support).

The interface of the generated classes is a little polluted to use them as domain objects.

This has nothing to do with LLBLGen, but is all result of using the data access entities as domain objects.

8.Productivity: If we use the LLBLGen generated entity classes to replace the domain objects we may save some time and effort. What percentage of the total effort? Does it provide enough value for you? ..need to consider these questions before we make a decision.

If we go with a domain layer over the entity classes there is not much productivity gain. Or am I missing something here???

Disclaimer: The above is based on some preliminary evaluation of the products.

I would like to hear from someone who has used both of these products seriously.  ¶ 6:13 AM