.NET Answers

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 Related Items:

Sega Jump Pack - Force feedback moduleThe Jump Pack is a wonderful peripheral that adds force feedback to the Sega Dreamcast experience. With games that support it, you can actually feel e... Read More >

Star Wars: TIE Fighter Collector's Edition with Behind the Magic ModuleThis top-selling space combat simulator writes a new chapter in Star Wars gaming. See the immortal conflict between the Imperial Navy and the Rebel Al... Read More >

Petsafe RFA-188 3-Volt Lithium Battery ModuleReplacement battery for Little Dog No Bark Collar model No. PBC00 10782. Easy to use coin slot for battery installation. Waterproof seal. On Off function built into the battery module by turning to appropriate settings.

Related Post

• DotNetNuke 5.x Can’t Move Module On A Page
• DotNetNuke Modules – Creating the PA
• DotNetNuke Modules – Retrieving Settings
• DotNetNuke Modules – Module Settings
• DotNetNuke Modules – Finding The Page a Module is On

Bookmark to:

Hide Sites

9 Responses to “DotNetNuke Modules – Foundational Concepts”