{"id":29,"date":"2008-10-14T17:24:47","date_gmt":"2008-10-14T21:24:47","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/brandonhaynes\/?p=29"},"modified":"2008-10-14T19:28:23","modified_gmt":"2008-10-14T23:28:23","slug":"using-the-linq-to-sql-adapter-in-a-dotnetnuke-module","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/2008\/10\/14\/using-the-linq-to-sql-adapter-in-a-dotnetnuke-module\/","title":{"rendered":"Using the Linq to Sql Adapter in a DotNetNuke Module"},"content":{"rendered":"

In a previous entry<\/a>, I discussed a potential solution to a longstanding problem.\u00a0 The DotNetNuke CMS framework allows declaration of an object qualifier and database owner on a per-installation basis.\u00a0 This effectively varies the fully-qualified database entity names at runtime.\u00a0 Because the Linq to Sql system by default utilizes a class attribution approach, it does not lend itself well to such runtime adaptation.<\/p>\n

Here I describe the steps necessary to use Linq to Sql within a DotNetNuke module in a reliable, distributable manner.<\/p>\n

<\/p>\n

1. Connect to your DotNetNuke database and add a set of Linq to Sql classes to your project<\/h4>\n

There exist thousands of tutorials<\/a> regarding this part of the process.\u00a0 I suggest starting out with Scott Guthrie’s excellent introduction<\/a>.\u00a0<\/p>\n

2. Download the DotNetNuke Linq to Sql Model Adapter<\/h4>\n

The model adapter is located on the CodePlex project site<\/a> and may be downloaded here<\/a>.\u00a0 The debug and release versions will contain a single assembly (BrandonHaynes.ModelAdapter.dll); copy this library to your project directory and include a reference to it in your project.<\/p>\n

A sample module (source and install versions) and additional documentation are also available on the CodePlex site.<\/p>\n

3. Update your DataContext to derive from BrandonHaynes.ModelAdapter.DotNetNukeDataContext<\/h4>\n

To use the adapter, you must change the base class of your DataContext to the specialized DotNetNuke adapter.\u00a0 This is most easily accomplished by opening your Linq to Sql classes, right-clicking anywhere within the designer area, and selecting “Properties.”<\/p>\n

Locate the Base Class line and change to “BrandonHaynes.ModelAdapter.DotNetNukeDataContext”.\u00a0 Since the adapter will automatically override the connection string specified in your DataContext properties, I suggest leaving the original value therein.\u00a0 Doing so will cause a parameterless constructor to be automatically generated, preventing you from being required to supplying a useless connection string during instantiation.<\/p>\n

\"A<\/a><\/p>\n

4. Compile and Enjoy!<\/h4>\n

That’s all there is to it.\u00a0 At runtime, the adapter will automatically detect the existing metamodel constructed by your metasource (by default via attributes on your classes, properties, and members) and adjust them to reflect the DotNetNuke object qualifier and database owner.\u00a0 No further intervention is required by the developer.<\/p>\n

Closing Comments<\/h4>\n

This project is the result of an informal experiment; having heard that runtime meta-model manipulation was not possible, I wanted to verify and determine if this was indeed the case.\u00a0 I expect that issues will arise, and would appreciate feedback about implementation experiences.\u00a0 I am particularly interested in hearing from anyone who is actually successful using this library.\u00a0 Specific issues should be logged in the CodePlex issue tracker<\/a>.<\/p>\n

B<\/p>\n","protected":false},"excerpt":{"rendered":"

In a previous entry, I discussed a potential solution to a longstanding problem.\u00a0 The DotNetNuke CMS framework allows declaration of an object qualifier and database owner on a per-installation basis.\u00a0 This effectively varies the fully-qualified database entity names at runtime.\u00a0 Because the Linq to Sql system by default utilizes a class attribution approach, it does […]<\/p>\n","protected":false},"author":1933,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3062,142],"tags":[3070,19470,3278],"class_list":["post-29","post","type-post","status-publish","format-standard","hentry","category-dotnetnuke-dnn-content-management-system","category-technology","tag-dotnetnuke","tag-dotnetnuke-dnn-content-management-system","tag-linq-to-sql"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/29","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/users\/1933"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/comments?post=29"}],"version-history":[{"count":1,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/29\/revisions"}],"predecessor-version":[{"id":84,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/posts\/29\/revisions\/84"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/media?parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/categories?post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/brandonhaynes\/wp-json\/wp\/v2\/tags?post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}