Linq to Sql support added to LLBLGen Pro

Imagine, you're sitting at your desk and you're using the Linq to Sql designer in VS.NET 2008 and you have, say, 50 entities in your model. You're happy about how things are progressing. It took a while to get the model set up, considering the wicked table and field names they cooked up in the DBA dungeon, but after some swearing and too much caffeine, it's done. The model which is smiling back at you is what you had in mind.

Rain slams against the window and the DBA you have heard about but never had the chance to meet in person, walks into your office and with her whiskey-shaped voice she almost whispers into your left ear:
"Son, I've updated a few tables in your catalog schema, hope you don't mind. See ya!"
Before you can ask her why she found it necessary to do such a terrible thing to you, she's dissapeared, back to her basement.

In shock, you stare at your shiny Linq to Sql designer, in it your 50 entities in full glory. Which tables were changed? What has she changed? WHAT!? You start telling yourself not to panic, when the idea of checking manually each and every of those 50 tables for changes, manually rebuilding the Linq to Sql model, re-doing your inheritance hierarchies, renaming the fields is causing a slight increase in sweat production. Why did you decide to wear this grey shirt to work, today!

Sounds familiar? Well, every Linq to Sql user will sooner or later get into this position. The problem is caused by the fact that the Linq to Sql designer doesn't have a model refreshing feature: when the database schema changes, you can't simply say to the Linq to Sql designer: "Hey buddy, I heard from our DBA overlords that you've some work to do. Ping me when you're done, OK?" and you get your model refreshed with the newest meta-data from the updated catalog schema and migrated to that updated schema.

Luckily, we've a solution for you. Yes, honestly, we do. You see, the designer of our O/R mapper system LLBLGen Pro has model refreshing and migration built in, together with sophisticated name construction schemes and inheritance hierarchy migration. It also packs a state of the art, task based code generator engine. So we wrote, in a single day, a couple of templates for our code generator engine, which can now produce Linq to Sql classes and mapping files out of a SqlServer project.

This gives you the option to update your model with the updated database schema meta-data without blinking an eye. On top of that, the code it produces is generated by templates. These templates are extensible and as our code generator engine is task based, you can add whatever you want to the pipeline: checking out code, compile the end result, you name it. Of course, command line tools are provided so refreshing, migrating and re-generating the code is completely controllable from the command line. We already chopped up the single code file the Linq to Sql designer produces for you, so you don't have to deal with a very large file with the model: every entity gets its own class. The only downside is that you can't update your model in the Linq to Sql designer anymore. But, why would you?

The templates are currently in beta, and available for our customers. If you're interested in giving them a testdrive, but not a customer of LLBLGen Pro, no worries: leave me a message via the contact form or below in the comments and I'll mail you the template package so you can use them with our 30-day trial installation.

A small note for the people who see conspiracy theories in every corner: no, we're not abandoning our own framework. On the contrary . Linq to Sql users already use Linq to Sql, but as we can provide some additional tooling for those people, why not?


  • How about releasing a scaled down version of LLBLGen that only has that feature, for free? It would create a great introduction to your product for those who have never used such a thing, and would get them thinking of the advantages of moving to your own model.


  • Guy: the problem with any project is that you have to re-create your model if the db changes. This can become a pain if you have any inheritance hierarchy onto a table or you have to rename fields for example.

    Sure we can create a leaner version and give it away for free, but last time I checked at the grocery store, they didn't give away their stuff for free either ;).

    It could be a first step into the world of our framework, but frankly I think that most people using linq to sql or entity framework for that matter, are told to use it and switching isn't an option.

  • I grabbed the templates and started working with them. In the readme, it states that LinqToSql doesn't support abstract inheritance bases, but it does(Set the "Inheritance Modifier" Property on the table in the O/R Mapper - it pops out as a "public abstract partial class").

    LinqToSql lso supports sealed sub-types, something not supported in the LLBLGen framework (At least I haven't found it yet. I'm still exploring... So many cool tools in there and so little time to get to play with them.)

    Guess that abstract keyword might be something to add to the templates. I really like what you guys do. Now, has anyone turned LLBLGen into a Visual Studio Extension yet?

  • Just realized that the abstract base could come out as an "internal abstract partial class" if you change the Access Modifier. Sorry if anyone got confused.

  • Neil: I messed with that abstract stuff a while, as it gave me a bit of a problem in inheritance hierarchies: the abstract class can't have a discriminator value, but it has to as it has to have a discriminator value. :) So you're in a catch 22. At least, I couldn't solve it without dropping the 'abstract'.
     We don't support sealed indeed, as we find 'sealed' a keyword which shouldn't be used that much.
    Thanks for the kind words! :)
    For extension: we're looking at that for v3.

  • Scott and Guy:

    I'm just a biased customer but one thing to consider is how much time this tool can save you -- in my case, LLBLGen Pro paid for itself in the first 3.82 hours.


  • OK, I'm confused :-) Does it use the LINQ to SQL designer, or does it have it's own? And if it has its own then why do you say "The only downside is that you can't update your model in the Linq to Sql designer anymore."

    BTW: Great idea with having a file per entity. Can I specify what folders those files should go to?

  • pbz: it doesn't use the linq to sql designer, as it uses the llblgen pro designer :) The downside comes from the fact that the llblgen pro designer uses its own project file, so if you update the dbml file in 2008, these changes aren't reflected in the llblgen pro project.

  • Hi Frans,

    I am not LLBLGen Pro customer, but I would like to check out LLBLGen Pro 2.6 Beta, along with LINQ to SQL support and Dynamic Data support.

    Can you please drop LLBLGen Pro 2.6 Beta, classes (Dyanmic Data), and templates (LINQ2SQL) here:

    Thanks, Kevin

  • Kevin: they're on their way. If you don't receive them, they're probably caught by hotmail's spamfilter which blocks zip files. :)

  • Great story Frans, got everyone to look at me when I was ROFL-ing ;)

Comments have been disabled for this content.