Dynamic Data and 3rd party o/r mappers is a fact

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.