From the Desk of Brandon Haynes

The .NET-supplied DataContext allows Linq to Sql development using the attributed model automatically generated by a Visual Studio designer. However, when deployed within DotNetNuke, these attributes do not pick up the database owner and object qualfier required by DotNetNuke.  Because of this, large-scale deployment of modules using Linq to Sql is infesable, and modules using the technology are unfortunately limited to internal applications.

To rememdy this issue, I have developed an adapter that converts the attributed meta model generated by the designer into a DotNetNuke-compatable model that uses both the object qualifier and database owner specified by an end-installation. 

My goals for any satisfactory solution were as follows:

• Allow run-time adjustment of an attributed MetaModel based on DotNetNuke database owner and object qualifier (no irksome additional meta-schema)
• Continued use of the Visual Studio Linq to Sql designer (no need to support a custom designer)
• No tedious changes in the compiler-generated code
• Continued use of an attributed-meta model (and thereby no external schema deployment files)

It is unfortunate that the object model exposed by Microsoft is so frustratingly difficult to extend.  The Linq to Sql meta-objects are overwhelmingly read-only (and, frustratingly, the AttributedMetaModel subclasses are internal and sealed).  Indeed, it seemed that there was no simple remedy to the problem at hand.

My solution utilizes a two-step approach:

• An AttributedMetaModel is generated based on the attributes automatically created through the designer (Goal 2 and 4). This model is walked to generate an adapted schema (Goals 3).  Walking is reasonably inexpensive, and since the models are cached by type, performance is not affected.
• This schema is transformed into an adapted model, which is cached and returned (Goal 1).  Models are thread-safe; caching is an easy performance improvement.

I use dependency injection to adapt attributed entities (database, table, and function names) into their adapted counterparts. A DotNetNukeAdapter is included for this particular domain. Additional adapters could easily be constructed for other domains, should any arise (to illustrate this point, a NonTransformingAdapter is included in the release, which performs no transformations).

Click here to access the project site for additional details and downloads.  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

B

Note

This project is still in an embryotic, beta form.  I have performed limited testing, and have distributed an alpha version to a selected few (thanks especially to Michael Washington for taking a look).  Until satisfactory results have been achieved with a wider audience, I caution against production deployment.  Proceed with caution.

Be Sociable, Share!

• 
•