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?
In the latest public preview of Microsoft's Dynamic Data, they've added something else besides what's publicly advertised: support for 3rd party O/R mappers! 
A couple of weeks ago, Bryan Reynolds mailed me about LLBLGen Pro support in MS Dynamic Data. I initially hadn't payed much attention to Microsoft's upcoming Dynamic Data initiative, as it's more geared towards web developers and was Linq to Sql / Entity Framework only as it seemed. He gave me a demo of Dynamic Data using Shared View (which works pretty well) and it got my attention. It's a clean, easy to use technology to get smaller websites which have to deal with data-entry, up and and running in no time.
There was a problem though: it seemed to be using Microsoft's own O/R mapping attempts only. So I mailed Scott Guthrie and explained that my enthousiasm was triggered by a demo of Dynamic Data and if they would consider opening up their code to support 3rd party O/R mappers as well. Within a day Scott hooked me up with some of the team members (David Ebbo and Marcin Dobosz) to see what could be done to support 3rd party O/R mappers. They provided me with a private build with some internal classes made public so we could check whether these were enough to provide meta data to the Dynamic Data engine so it could build the pages with LLBLGen Pro code as its O/R layer instead of Linq to Sql or the Entity framework.
It took a few iterations to get things right, but in the end it payed off: the meta-data provider API is sufficient enough to provide all the meta-data necessary and also to get back at runtime additional meta-data the O/R mapper added to the providers. The API is generic enough for 3rd party O/R mappers, if they use a context or not. Microsoft has decided to make this API public in the latest public CTP release of Dynamic Data, so any 3rd party can implement the metaprovider classes required.
Can every 3rd party O/R mapper work with Dynamic Data?
In theory: yes, I think it can. It needs two essential building blocks though:
- Linq support. The Linq support is essential as it is used to produce filters on related entities.
- A Datasource control which has SelectParameters support
Both elements required are time consuming projects to build, depending on how far you will go of course. A simple Linq provider might work OK for Dynamic Data and a simple datasource control might do too. Combined the LLBLGenProDataSource control and the Linq to LLBLGen Pro provider took almost a year to build in full. Looking back I now know it was well worth the investment: a Linq provider is essential for an O/R mapper to succeed in the .NET world of tomorrow, and a datasource control which works nicely with your O/R mapper is too.
For LLBLGen Pro customers who want to try out the dynamic data support, please contact us via email or our forums so we can email you our package with templates and DynamicData support classes. Our Linq support is available in beta in the beta of LLBLGen Pro v2.6, which was released yesterday.