LLBLGen Pro for .NET and .NET Core - Database Entity Modeling with any ORM
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.)
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.
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.
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.
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.
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!).
Quick Model is also nice if you want to visualize (and change) relationships between just a few of your many tables.
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.
About Newsletter
Sometimes the project get deployed but the database has changed... this is the reason we are enforcing code first approach on our projects now.
Sometimes the project get deployed but the database has changed... this is the reason we are enforcing code first approach on our projects now.
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
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 :)
John
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.
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 :)
Thanks all for the heartwarming words :) It's great to read our work is still loved and used! :) More to come! :)
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?
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')
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..
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.
Comments are closed.
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.