Learning about LLBLGen
time to read 7 min | 1337 words

I’ve been reading the LLBLGen documentation for the last couple of days, and it’s an interesting read. I think that I should say first that I have a very strong bias toward NHibernate, so please don’t think that I’m an impartial observer here.

Before I really dove into NHibernate, I read Hibernate in Action (still the best book for learning Hibernate, in my opinion). I’m trying to give LLBLGen (who came up with this name? It is worse than Microsoft’s naming) the same treatment, and read the entire manual before I dive into the code. This way I will have a fair understanding of the system as I play with it. I don’t think that O/RM are something you can just start cowboy coding, not if you want to understand what is going on, at least.

So far, one thing is very clear: LLBLGen is not Hibernate. Not even close. The design decisions that have been made are completely different than the ones that were made for Hibernate. (That is not to say that they are wrong, just that they are different than what I am used to). I found myself wonder “Why did they do that for?” fairly often, but the documentation is very good, so I usually find the reasons sooner or later. I do wonder how much of the difference is because of the different scenarios that affected development.

In .Net, rich client applications are common, in Java, very rare. This means that Hibernate is heavily biased toward web development approach, with short lived sessions and request type of actions. (Do this, fetch that, etc), in those scenarios the entities that you are working with are going away when the request is over. LLBLGen seems to be designed with rich clients in mind, where the entities can last for a long time. This change is one of the major differences between the two, and it affects quite a bit of the way both frameworks are structured.

Some things that I noticed so far were:

  • What the documentation calls SelfServing entities looks a lot like ActiveRecord object (the pattern, not the library).
  • There seems to be a high level of interaction with the database in the code level. (There seems to be a lot going on with explicit IDs, field indexes, etc. It is wrapped in enums, but it is there). I'm not sure how much of it is in my face when I'm coding, though.
  • I really don’t like the way you fetch entities from the database. You need to create a new instance of the object and pass the PK to the constructor. It looks like doing stuff in reverse to mean. Worse, this means that you need to know the type of the object that you are loading at compile time. I’m not sure that there are ways around it, since the documentation states that this is a by design choice.
  • One thing that I really liked is that it is possible to do updates on more than one entity easily. What I mean is that I can make LLBLGen issue this statement “UPDATE Customers SET Valued = 0 WHERE LastPurchase < getdate() – 365”. I am not aware of a way to do the same in NHibernate (and in this case I would probably just call a stored procedure), but it is very good to be able to do this.
  • LLBLGen Predicates are comparable to NHibernate’s Expressions, which are extremely useful. I don’t see something similar to HQL; I don’t like AST that much.
  • There doesn’t seem to be a way to handle cascades properly. This means that I would have to do it manually, and I’m not enthusiastic about managing this myself. This is one of the places where it is easy to get it wrong in NHibernate, so I can see why this decision was made. It is probably possible to handle this within the database itself, but I'm not sure all the databases supports it.
Just to be clear, I wrote this post without doing anything real with LLBLGen except reading the documentation and reading the code in the sample application and after investing a lot of time and effort into NHibernate, there is no way I can be impartial.

NHibernate is a complete abstraction over a database, which means that in 99% of the cases, you don't feel like you are working against a database. LLBLGen is not a complete abstraction, the database is most definately there if you need to use it. From reading the sample application source, I think that you can certainly avoid the database if you don't want to. It means that LLBLGen allows to take advantage of some features of the database that are not possible / easy to do so in NHibernate, like updating sets of rows in one query.

NHibernate seems more capable in the area of taking a convulted of schemas and presenting an OO view of it that you desire. I'll freely admit that my scenarios are not usual, and that I tend to take advantage of features that I probably shouldn't.

There isn't a conclustion to this post, because I don't have one. In general, I would like to use NHibernate, since I'm very familiar with it and what I can do with it. LLBLGen has several features that I wish that I could have in NHibernate (but I don't see them coming, since they require different design and approach).

Tags:
Tweet Share Share 0 comments
Tags: