nHibernate versus LLBLGen Pro

Question

I am trying to work out with ORM tool to move over to and have narrowed it down to two candidates.

nHibernate or LLBLGen Pro

Please can you guys give me pros and cons in using both these tools especially if you have experience in both. I am not really interested in any other tools but am wanting some heads up so I can decide which tool to spend time learning....

I already know that one is free and one isn't, I also know that nHibernate might take some learning....

Many thanks, Richard

Isham

Answer 1

I have used both. At first I was sold on nHibernate and refused to try anything else even though I knew about other options.

With LLBLGen Pro, I was skeptical, but soon saw the advantages as well. I have not totaly abandoned nHibernate. I will continue to keep int in my "box of tools". I have found LLBLGen useful in some cases especially when interacting with a database that already exists and you have no choice of re-designing it. It takes less than an hour (depending on size of database of course) to generate my LLBLGen Entity Objects from the database, as opposed to having to code all of it manually with nHibernate, AND do the mappings. nHibernate is missing a nice graphical interface to create the mappings. This fact becomes even more important when the database is massive with thousands of tables that you need to potentially access in your application.

Although LLBLGen is more of a Data Access Layer generator (And I am not normally a fan of DAL generators), it has a lot of features a "true ORM" tool would have. In my opinion it has the best of both worlds. Once you start working with it you start to realize that it is very flexible and extendable. One part I like a lot is that it is possible for me to create partial classes for the generated entity objects, where I can code in my business logic, as well as validation.

The code generation is templated so you have full control over the code it generates. With nHibernate I find myself writing some of the same kind of code over and over again. With LLBLGen I can generate it and get to focus on business logic and issues quicker.

For someone who is just starting to use ORM type tools, I really recommend to start with LLBLGen, because nHibernate can be overwhelming. And in the end you will have achieved the same result (More or less).

Edit #1: LLBLGen now also has 100% support for LINQ. (So if you like LINQ to SQL for that reason) further LLBLGen can support many databases, where LINQ to SQL is only for Microsoft SQL Database.

Edit #2: According to Graviton you can use CodeSmith to do some of the code generating for you for nHibernate. That is really cool, but for a newcomer to ORM I would still recommend LLBLGen. To me that is adding more dependencies where LLBLGen has it all in one package. Also like I said before the learning curve is so much less steep and you will get the same benefits, which will also help you ease in to nHibernate if you ever decide to go there.

Seraphina

If you are looking for code generating capabilities for NHibernate, you can look at CodeSmith; it has nhibernate support: itscommonsensestupid.blogspot.com/2009/04/… – Savage

NHibernate supports Linq. Have you tried Active Writer (A graphical designer for NHibernate)? using.castleproject.org/display/Contrib/ActiveWriter – Assuntaassur

Thanks Michael. I guess it is only a matter of time until that gap is closed for nHibernate with 3rd party tools like Active Writer. I'll have to give it a try and see how well it works :) – Seraphina

Our experience showed, that the LINQ to LLBLGEN is not fully functional. I don't know exactly if the bugs are fixed in the latest version but currently we sadly had to stop using complex LINQ queries to LLBLGen. Just as an annotation - not really as a plea against LLBLGen. – Krystin

@Krystin That's news to me. I have never had an issue with it. Maybe you are doing extremely complex LINQ queries? If that is the case then I would not have run into that problem, since I prefer to create views, or stored procedures, for overly complex database queries. Then, I generate entities off those using LLBLGen. – Seraphina

I had a pretty complex where clause to handle filtering of nullable ints. It didn't work. In general we had problems with nullable values. – Krystin

@Krystin there's almost certainly simple workarounds for those things, have you mentioned them on the LLBLGen forum? In my experience, bugs are solved most of the time by the LLBLGen team within days (sometimes hours) with a new build. – Hrvatska

We use LLBLGen LINQ for extremely complex stuff without problems. It's not the greatest tool for Domain Driven Development, but if you like to think about things from the perspective of the database first, it's a clear winner. – Batt

Version 3 of LLBGen now targets NHibernate, Entity Framework and Linq to SQL. – Homoiousian

There is a Visual Designer for NHibernate available, see this website for the tool: slyce.com – Smoky

@RobAngelier Thanks! I have 2 reactions to that: 1) That tool didn't exist when this question was answered 2) It's not free. – Seraphina

@Seraphina true, but you where not asking for free tools. I just posted it in case someone every needs it. – Smoky

This answer should be taken with a grain of salt these days: There are at least two (if not more) capable and relatively Database-To-Model tools for NHibernate these days. That is, NHibernate can now be used "Database First" as well. (FWIW: I belive Database-First is The Correct Way ;-) – Garden

@pst Obviously, I wrote this answer 3 years ago. Naturally the landscape has changed since. 3 years is a long time in the world of software development. – Seraphina

Answer 2

The major difference is that LLBLGen is a code generator, while NHibernate is a "true" ORM library.

LLBLGen advantages:

• Easy to use model designer. Can import your existing database schema
• Fully typed object model and query language

LLBLGen disadvantages:

• You need the designer application to change your model
• Not free
• Can bloat your code because a lot of code is generated

NHibernate advantages:

• No designer application needed. Only code
• Widely used (based on the most popular Java ORM, Hibernate)
• Very powerful for mapping any data model you can imagine
• Open source

NHibernate disadvantages:

• Hard to learn
• Not as strongly typed as one would like (especially queries)

Of course, this is just my personal point of view...

Howell

So which one is your favourite? Which one would you recommend? – Isham

I wouldn't choose either, but I've had to use them both and I prefer NHibernate over LLBLGen. The reason is that I hate dependencies on external code generation tools, but that's a personal thing :) – Howell

I've used both, and in general I'd choose LLBL ... primarily because LLBL can get you up and running with far less work/code. If you can relate more to database tables than abstracted domain objects, LLBL is for you. – Batt

Philippe - not true. LLBLGenPro is an ORM with a built-in code generator, not just a code generator. – Batt

LLBLGen can't be used without the code generator, so it's essentially a code generator, even if the generated code calls an internal ORM library – Howell

Answer 3

I typed up a fairly long answer before realizing this was a somewhat old question. Oh well. It's still very relevant.

You have narrowed your list to the two best candidates for an ORM in the .NET world. I have limited experience with either, but I've read extensively about the pros and cons of both. They really serve somewhat different needs in different ways.

In the upcoming LLBLGen Pro 3.0, Frans Bouma has talked about adding features to generate NHibernate mappings. So, it's not even necessarily an either/or decision.

If you want to do "class first" design (as opposed to "database first" design), NHibernate is pretty much your best and only option right now (neither LLBLGen Pro nor Entity Framework support this mode, although it sounds like Entity Framework is improving it's support in the next version).

NHibernate and LLBLGen Pro both work hard to work well with legacy databases which you can not change and have to live with. That is their common strength. They both also work with Linq. They both also support some amount of graphical modeling, although LLBLGen Pro is far superior in this regard (ActiveWriter for NHibernate feels like the LinqToSql designer in Visual Studio, but it's not really as feature rich).

LLBLGen Pro has much stronger code generation abilities, but too much code generation can lead to compromised testability and maintainability (one small tweak can cause massive amounts of code to need retesting).

While NHibernate wants to help you work through fairly complex object/relational mapping scenarios like class inheritance, LLBLGen Pro is really just exposing your database as a data layer and business objects in a very quick way.

If you can purchase LLBLGen Pro and have some time, I would try both and see which one better meets your needs. Learning both ORMs is good for your resume in any case.

So, in the end, I would say it's situational. The cost of NHibernate and its lack of serious flaws make a pretty compelling case in the majority of situations.

Assuntaassur

Thanks for your comment... I voted you up! I still am mulling this one over! – Isham

Answer 4

The new version of LLBLGen Pro (3.0) allows you to generate code for NHibernate, so don't have to choose :). It also allows you to split up your entities into different domains.

I still prefer the LLBLGen pro runtime though, the LINQ interpreter is more complete and it has better change tracking of fields.

Unfortunately there's not many new features in the new LLBLGen Pro 3.0 runtime, as the creator first wanted to focus more on tooling than improving the existing framework.

Hrvatska

Note that 3.1 (recently released) included both speed and memory management enhancements for the LLBLGen Pro runtime. – Stratigraphy

Answer 5

I've used nHibernate, LLBLGen Pro, a custom data layer from my consulting company, the Enterprise Library, and LINQ. LLBLGen is by far my favorite and it allows writing one business layer that can talk to different types of databases using the same code providing database independence! Another incredible feature is it allows multiple connections to different databases. This is very useful when at a large company and one system is written in Sql Server and the other you have to interface with is in Oracle.

LLBLGen Pro is an amazing product backed up by Frans who is very active and works hard to fix issues. LLBLGen is like PhotoShop, it is an incredible tool and that can do amazing effects in the hands of someone who knows how to use. And like any tool that saves lots of time, it takes a week or two to learn how to use it, but will save months later on your project.

Not only did it speed up the DAL generation side of my app, it is also easy to create queries in the Business layer and send to the presentation layer. It made it easy to create an enterprise class application.

If one really wants to use nHibernate, start with LLBLGen Pro and generate the nHibernate code. If later on your department decides to switch from nHibernate to LINQ, you are covered. Want to switch from Sql Server to Oracle? This is possible and relatively easy with LLBLGen whereas with manually coded nHibernate code, you have to rewrite everything which is almost impossible to cost justify.

Frans was also available and answered some of my questions.

Dorking

Answer 6

Don't forget one of the greatest plus point of Hibernate: HQL. With HQL, your SQL skill is not wasted. And Hibernate provides very nice, seamless support for native query as well. If you have some weird, out-of-standard database, it's almost certain that you need your SQL skill at some point, and good luck with LLBL!

Idden

I agree and I respect nHibernate. But please don't knock LLBL either because it does have support for native SQL. LLBL is just different in that it is the other way around, data driven. Where nHibernate is Domain Driven and you can push off database stuff till much later in your development. – Seraphina

How to run native SQL in LLB is a very closely guarded secret. Go ahead, ask them how to do it on the forums! :) – Gdynia

Answer 7

For me it boils down to database centric (LLBLGen Pro) vs. domain model centric (NHibernate).

Since I'm a DDD/OO guy, the choice has always been very easy for me, but I do see why LLBLGen Pro is popular.

Roop

NHibernate works with Database-First designs as well with Domain-To-Model tools. Historically it was always Model-First, but again, there now exists tools to generate (and update) the Model from the Database. – Garden

Answer 8

We use LLBLGen at work, and it's reviled -- namely because we have multiple similar schemas, but you need to have a different DLL/Class library for each schema, meaning that it becomes annoying to write code that can target any schema.

Of course, that's an unusual environment, so it may not apply to you.

Loewe

you can use schema name overwriting, so you can target similar schemas with 1 code base. This can be done in the config file of your application but also at runtime through calls to DataAccessAdapter. – Typebar