Scott Hanselman

LLBLGen Pro for .NET and .NET Core - Database Entity Modeling with any ORM

June 12, '17 Comments [20] Posted in Data
Sponsored By

There's opinionated frameworks, and then there's opinionated frameworks that also respect your opinion. LLBLGen is one of those. For many years it's been a great entity modeling tool as well as an excellent ORM (Object Relational Mapper.) It also supports all major ORMs in the .NET space like Entity Framework, NHibernate, Linq to Sql as well as, of course, their own included LLBLGen Pro Runtime Framework. It works with VS2015 and VS2017 and is actively supported and extremely actively developed. It's because of that active development that I wanted to check it out. It's got Getting Started videos and a TON of docs, so I figured I could do some damage pretty quickly with a 30 day trial.

NOTE: Just a reminder, I don't do sponsored posts for software. I just felt like checking out LLBLGen because it's been a few years since I looked at it least. All my observations are my own, unfiltered, as I know you like them, Dear Reader.

You can do Database First - a technique that is crucial for so many of us with existing databases but often downplayed with other ORMs - as well as Model First and then generate classes.

I decided to start with one of the newer SQL Server 2016 sample databases called Worldwide Importers. There's localdb versions, Azure SQL Database versions, and SQL Server 2016 backups. I made a database in Azure, uploaded a "bacpac" file to Azure storage, and imported the database into SQL Azure. Although I certainly could have done the work locally, I can get more horsepower in the cloud.

When I make a new Project in the LLBLGen GUI I can pick from a ton of different ORMs including 5 (!) versions of Entity Framework including EFCore, as well as NHibernate 4v and Linq to SQL (which is a nice touch as I have two L2S projects still in production.)

LLBLGen supports a bunch of ORMs

The WorldWide Importers sample is a nice one as it's typical and non-trivial in complexity. I pointed LLBLGen at it and let it rip. Make sure you wait until your database is totally restored into SQL Azure or your SQL Server or you may get weird errors about Zombie Transactions.

LLBLGen chewing on the DB

When it's done, you'll get an Errors & Warnings pane that will tell you how many stored procs, tables, views, etc that were imported, and that they are "unmapped," which is cool since you haven't mapped them.

Smart Errors in LLBLGen

You can switch your Target ORM Framework after you've imported your Data Model, but you really should put a little thought into how your database is structured and whether or not your preferred ORM supports all the features you (may) have used heavily in your Database. For example, if you're a very "stored proc"-style shop, it would be a problem if you really wanted to use an ORM that didn't support stored procs.

LLBLGen is rather extraordinary in that it not only has smarts about what's possible and what's not, but it also offers you a multiple-choice solution framework when something is wrong. For example, there's a mapping here that isn't support, so it's offering me three options to fix it, including (of course) changing the offending entity by changing/adding fields.

LLBLGen offers multiple fixes and can do them right there in the Errors pane

Once you have a valid model and have corrected any issues and/or made appropriate changes, you can Generate Source Code for your target platform, language, and ORM Framework.

Generating Code with LLBLGen

Make no mistake about it - there's a LOT of depth here. There's multiple kinds of templates and tons of options. You may not get it all right on the first try, but it's very forgiving. Just remember where the authoritative source of truth is. Is your model the truth? Or your database? As you move forward (depending on where you started) your source of truth will likely change. You can use any of the many code generators or expand them with your own modifications and metadata.

You'll also likely get addicted to the nice visual editors for entities (a good thing!).

LLBLGen Visual Editors

Quick Model is also nice if you want to visualize (and change) relationships between just a few of your many tables.

LLBLGen Visual Designer

If you get fast enough, with practice you can use the Quick Model editor and it's Command Input palette to model most of a new database when interviewing domain experts. The visual designer is fast and flexible.

I've truly barely scratched the surface of this deep tool. The pricing is very reasonable considering all it does.

Have you used LLBLGen or similar tools lately? What's been your impression?


Sponsor: Big thanks to Raygun! Don't rely on your users to report the problems they experience. Automatically detect, diagnose and understand the root cause of errors, crashes and performance issues in your web and mobile apps. Learn more.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Monday, 12 June 2017 07:13:00 UTC
I've used it in several projects where I've used the designer together with the LLBLGen runtime framework. It is a great product.
The only caveat that I've had is that the LLBLGen runtime framework (the actual ORM) is monolithic (you have to have all your entities in one VS project) but if you are fine with that restriction then it is phenomenal.
Dalibor Čarapić
Monday, 12 June 2017 07:53:49 UTC
Thanks for the great article! :) About the azure problems: the SQL Server driver we have doesn't have transient error recovery (a thing needed for SQL Azure, our runtime does have it btw) as before Azure didn't have meta-data available in the sql databases similar to normal sqlserver databases so we actually don't support database first on SQL Azure (only on non-cloud SQL Server instances). Azure seems to have the metadata now in a normal format so we'll add transient error recovery to the SQL Server driver so this won't be a problem in the future.
Monday, 12 June 2017 09:09:46 UTC
Seeing Frans Bouma's name, what a sweet blast from the past. Happy to see this project is still active.
Monday, 12 June 2017 10:35:54 UTC
I find it can be counter productive to do database first approach when you are working in a team and the project gets to a considerable size.

Sometimes the project get deployed but the database has changed... this is the reason we are enforcing code first approach on our projects now.
rosdi
Monday, 12 June 2017 11:42:07 UTC
Llblgen has been my favorite ORM since 2003. It has never let me down. There are two additional features that I would point out - the ability to modify it's templates in a way that suit you and the ability to easily connect model multiple catalogs. My last large app had a model that connected to both Oracle and SQL Server. Our model was clean and easily maintained due to LLBLGEN
Thomas Wagner
Monday, 12 June 2017 12:07:55 UTC
It is a great product. I've used the designer together with the LLBLGen runtime framework.
Sometimes the project get deployed but the database has changed... this is the reason we are enforcing code first approach on our projects now.
Monday, 12 June 2017 13:17:02 UTC
I'm a long time enthusiastic user of Llblgen Pro. I think you'll find that if you continue deeper into your investigation of the features and support, you will agree there is not a better product in this space.
Monday, 12 June 2017 13:17:12 UTC
Another thumbs up for Llblgen. My first ever project used a terrible product called NetTiers. The next project used Llblgen and it was a breath of fresh air. Then Ef, which was brilliant. Then NHibernate - meh. Would love to use Llblgen again one day.
Dave
Monday, 12 June 2017 22:19:14 UTC
This is a great piece of software. I have used it extensively for the last 12-ish years or so and my experience is that it is rock solid. (Of course, use the built-in support for transactions where appropriate.)

Sometimes I use it to generate other stuff beside DAL code.

There is a set of templates floating around out there that use LLBLGen to generate an entire site based on ServiceStack that you should check out if you haven't already.

Timothy
Monday, 12 June 2017 22:46:25 UTC
Been using llblgen for years now... The queries it compiles when executing are the fastest ones I've seen, and it allows for a LOT of customizations.
The EF on the other hand has a ton of issues and with every slightly bigger project, we always came to regret not going with llbl framework...

The concept of the adapter that saves a graph is miles ahead of ef's context that saves everything attached...(ymmv)

Awesome product (and great support btw), just keep it going :)
veljkoz
Tuesday, 13 June 2017 03:42:54 UTC
LLBLGen is the best ORM that I know of and is well supported. Frans as you can see from his post above is very committed and passionate about their product. It is rock solid and does a great job providing a robust feature set that does not sacrifice performance. We really liked the save object feature which saves a complex data object into multiple tables automatically. Also used the built in caching features. Have replaced (slooooow) EF on two projects and saved tremendous aka months of development time. Used database first mode.

John

John
Tuesday, 13 June 2017 05:17:46 UTC
@all Anyone have a data study on if ORM is actually cheaper to use in the full lifespan of a database storage based solution? I'm thinking about the 75% or more of the time the system is in maintenance mode after teh first production release.
Steve
Tuesday, 13 June 2017 19:35:35 UTC
LLBL is awesome, been using it for over a decade. Tried EF twice, both times a joke.

Wishing for an LLBL runtime for .net core. Our .net core plans are on hold until I can regen for core using the llbl runtime library.
hf
Wednesday, 14 June 2017 06:58:16 UTC
@hf

Later this summer we'll release our runtime for .NET core 2.0. As things are looking now we don't have any breaking changes except dependency injection, but we hope to find a workaround for that too :)
Wednesday, 14 June 2017 07:00:02 UTC
(wanted to add this to the previous post)

Thanks all for the heartwarming words :) It's great to read our work is still loved and used! :) More to come! :)
Wednesday, 14 June 2017 19:55:45 UTC
@Frans Bouma
Can we split the model in something called "modules", each of them contains a set of entities and generates into separated VS projects to use them independently?
Stanislaw Tristan
Thursday, 15 June 2017 06:33:33 UTC
@Stanislaw Tristan

Yes :) You can create multiple models in the project, by grouping the entities in different groups and set the grouping setting as 'separate projects'. This will make the designer generate separate visual studio projects in different folders, one for each group.

This way you can define multiple models on 1 database for example. Of course there shouldn't be any relationships between the groups, but the designer will test for that and let you know ;) To overcome this, you can e.g. reverse engineer a table in a second group and use it as a readonly entity (e.g. 'Product' is in group A as read/write, and as 'readonly' in group B, mapped onto the same table 'Product')
Thursday, 15 June 2017 07:14:26 UTC
LLBLGen is a great product, and I used it successfully in a few projects.
It's amazing what 1-2 people were able to realize, that tens maybe hundred of engineers in some other corporations working on a similar product, were not being able to match.

It's a pity that it's not backed up by a slightly bigger company - if mr. Bouma won't be able for some reason to work on it sometime in the future, I don't know who will be able to carry on the effort..
Tudor
Monday, 19 June 2017 10:25:42 UTC
I've been using it since 2005, moved to it from CodeSmith back then (anyone remember that one :)). A truly fantastic product, very comfortable to work with, rock solid reliable and has an awesome performance in terms of queries that it generates for complex chains of objects (which btw has been a major issue with EF in my company). It has a great query predicate building mechanism, a great visual designer and a templating engine. For example, it's very easy to construct a custom template which generates POCO classes aside from heavyweight entities and map one to the other via AutoMapper. What it does under the hood is also not that difficult to understand, there's even a way to optimize generated queries with hints, serialize entities and predicate expressions if needed, and much more.

The support is also great. Issues are quickly fixed or if the problem is really nasty, Frans himself will either provide a fix or a detailed explanation why something won't be implemented or how to bypass it with a workaround.

I just wish people would use it more and to finally get that corporate acceptance that the EF has. We strongly advocate it to our clients, but sometimes it's difficult to get their approval.
Monday, 19 June 2017 21:28:54 UTC
Thanks for the great write-up Scott!
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.