DotNetNuke Modules – Foundational Concepts

There are two design patterns that dotnetnuke relies on heavily, not just in the core code, but in any module you might develop.

The first is a three tiered architecture, or more appropriately a three layer architecture.  The second is the use of the Provider model.  If you don’t understand these two patterns, your first attempt at creating a module may end in frustration and possibly even disaster.  I don’t want to say that no one could write a module if they don’t understand these concepts, but I will go so far as to say that I would suspect any code that was written without understanding these two concepts.

We covered the basics of the three layer architecture several weeks ago while we were exploring database access.  The three layer architecture separates out the presentation layer (typically referred to as the view), the business logic layer (BLL), and the data access layer (DAL) into three distinct components.  This allows us the flexibility of changing either the presentation layer, the BLL or the DAL with minimal changes to the other layers.  Done correctly one could use the same BLL and DAL layer with both a Web application and a Windows Forms application.  In fact, I was able to place a Web Service interface over my BLL which a Windows Forms application is accessing to update a dotnetnuke module I created.

The second concept you’ll need to understand is the idea of Providers.  The best way of thinking of a provider is that they work like plug-ins.  But, unlike plug-ins that all obey the same interface, but provide different functionality, a Provider is providing interchangeable functionality.  The place you will see this when you are creating a DotNetNuke module is at the DAL level.  The default provider is the SqlProvider.  When you create your module, you’ll create a base provider class that defines the interface, and you will create a child class that defines the implementation for the MS-SQL database.  This model was initially created so that DotNetNuke could be run with either an Access database or an MS-SQL database.  The Access database support has been dropped but the provider model remains.  And, you can still find providers for the core DotNetNuke code from third party suppliers that support Oracle and MySQL.

In the DotNetNuke world, the classes that function as the conduit between the presentation layer and the data access layer are called Controllers.  This is another point of confusion if you are familiar with the three tiered architecture because one would normally think the class would be called “BusinessLogic” or something similar.  Frankly, I don’t have a good clear reason and I’d appreciate someone from the DNN team explaining it in the comments.  For now, just realize that when we refer to the controller class, we are referring to the business logic layer.


Other post in DotNetNuke - Module Development

Related Post

9 Responses to “DotNetNuke Modules – Foundational Concepts”

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail