Home » DotNetNuke - Module Development » DotNetNuke Modules – Advanced Architecture

DotNetNuke Modules – Advanced Architecture

misc_vol4_032 So far we’ve done all of our development assuming that we are developing our module for internal use.  To be fair, that’s what most of you all will be doing.  There are a lot more of you who will be developing modules for internal use who will be fine with the architecture I’ve already given you, i.e., all of the files in one project.

But what about commercial projects?

One of the major requirements you will need to consider with a commercial project is: How do you allow other developers to supply a provider for other databases?

Yes, it is true that the great majority will be happy with the provider you’ve supplied.  But since DotNetNuke allows other database systems to be used with it and since we are already coding our modules using the DotNetNuke provider architecture, why not make this available to others who want to use it?

The primary thing we need to do is to separate out the data provider pieces so they allow the user to swap the provider out with another one they’ve created.  To do this we will create two new projects and move our existing code into those projects.  Both of these projects will be Class Library projects.

The first project will be a DLL to hold our DataProvider interface.  You’ll create this in the same solution by right clicking on the solution node in the solution explorer and selecting, “Add” > “New Project…”

Select “Class Library” from the project list and give it a unique name.  I prefer to prefix the name the same as namespace and then name it “DataProvider”

You’ll then want to cut and paste the DataProvider.cs (or .vb) file from your app_code directory in the web project into the DataProvider project you just created.

You could stop here, but I find it makes a little more sense to also create a SQLProvider project similar to how you created the DataProvider project above and cut and paste the SqlDataProvider.cs (or .vb) file into that project.

You’ll need to have the web project and the SqlProvider project reference the DataProvider project so that they will both compile.  You will also need to modify the output directory of the SqlProvider project so that it puts the final DLL into the bin directory of your DotNetNuke development application.

 

Other post in DotNetNuke - Module Development

Related Post

  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • DotNetNuke Modules – Benefits of ArchitectureDotNetNuke Modules – Benefits of Architecture Now that we have something running, it's time to take a look at the various parts of the DotNetNuke framework.  But before we do, we need the all-important question, "Why do we […]
  • The point of a multi layer architectureThe point of a multi layer architecture I'm planning on doing a series of videos on multi-layer/multi-tiered architecture using LINQ, but before I get to that I thought it would be helpful to first discuss the advantages of […]
  • DotNetNuke Modules – Making Content PortableDotNetNuke Modules – Making Content Portable The last main feature of module development that we need to discuss is the implementation of IPortable.If you've ever worked with other content management systems in a corporate […]
  • DotNetNuke – Modules – Portal Specific ModulesDotNetNuke – Modules – Portal Specific Modules Many of you won't care too much about creating Portal Specific Modules because you'll be creating modules for an environment that only has one portal. However, if you are creating a […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.