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

  • 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 wrong, which...
  • DotNetNuke – Data Access Layer AlternativeDotNetNuke – Data Access Layer Alternative Now that I've explained the standard way of creating a Data Access Layer (DAL) for DotNetNuke, we can address the alternative method of providing this same functionality.You see, the only reason f...
  • DotNetNuke Modules – Anatomy of the ViewDotNetNuke Modules – Anatomy of the View Now that we've laid the foundation of DotNetNuke modules, it is time to start looking at the specific modules. While it would be practically impossible to cover every detail and every API feature o...
  • 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 care?" From a...
  • DotNetNuke Modules – Install DNN into VS 2008DotNetNuke Modules – Install DNN into VS 2008 Today, we will install DotNetNuke into Visual Studio so that we can create our first module. So fire up Visual Studio, and let's get going. I'll be using Visual Studio 2008 to walk you thro...