A software package a day: LLBLGen

LLBLGen is a Object Relation Mapper, or ORM. We started using it long before LINQ to SQL was available (or even discussed) and it have provided years of reliable data access with type safety that ADO.NET doesn’t provide inherently. (One can hand craft classes to mask this problem, but LLBLGen does that automatically via a code generator.) The question that I now have is with all the LINQ to Entities, should I continue to move forward with LLBLGen?

I have several pages on my site describing how to use LLBLGen… these pages were created in part to support other members in the team’s questions about basic operations of LLBLGen that are not well documented. This is not to say the documentation for LLBLGen is poor, but the basics are offloaded into example projects which makes a quick lookup of common usage patterns harder than it should have been. In part, this is because of the flexibility of LLBLGen: it supports multiple options which makes any specific use of the system somewhat unique. Enabling null types, how the classes are generated and extended, choosing between adapter (tight control over data access timing) and self servicing (which has excellent ease of use) and more all play into how the program is used.

We are now experimenting with dropping LINQ to Entities queries in place of our LLBLGen code. For now, LLBLGen has felt more mature and we have hit some roadblocks in more complex scenarios, but the draw of using the “standard” technology for a platform is appealing.

All of that out of the way, I can say that LLBLGen has been the backbone of my data access strategy for a very long time and it is hard to go wrong with the product. It is inexpensive, powerful and provides a strong basis upon which one can build upon to create their high level data objects or business tier. Even if LINQ to Entities works out, we will still be using LLBLGen in many situations for a long time. If you have found other solutions lacking, it is worth taking a look at LLBLGen.