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
- Creating DotNetNuke Modules - May 20th, 2008
- Creating DNN Modules - The Tools - May 22nd, 2008
- DotNetNuke Modules - Foundational Concepts - May 26th, 2008
- DotNetNuke Modules - Install DNN into VS 2008 - May 27th, 2008
- DotNetNuke Modules - Creating Base Modules - May 28th, 2008
- DotNetNuke Modules - Registering Your Module - May 29th, 2008
- DotNetNuke Modules - Where Stuff Shows Up - June 3rd, 2008
- DotNetNuke Modules - Benefits of Architecture - June 4th, 2008
- DotNetNuke Modules - Anatomy of the View - June 9th, 2008
- DotNetNuke Modules - Adding Actions - June 11th, 2008
- DotNetNuke Modules - DNN Controls - Label - June 18th, 2008
- DotNetNuke - Internationalization - June 25th, 2008
- DotNetNuke Modules - Internationalization (part 2) - June 30th, 2008
- DotNetNuke Modules - Labels w/ no Help - July 9th, 2008
- DotNetNuke Modules - LinkButtons - July 14th, 2008
- DotNetNuke Modules - Collapsible Panels - July 16th, 2008
- DotNetNuke - The Data Layer - Installing CodeSmith - July 22nd, 2008
- DotNetNuke - Modules - Creating The Tables - July 24th, 2008
- DotNetNuke - Modules - Creating Stored Procs - July 29th, 2008
- DotNetNuke - Modules - Portal Specific Modules - July 31st, 2008
- DotNetNuke Modules - Data Access Layer - August 5th, 2008
- DotNetNuke Modules - Data Access Layer - August 7th, 2008
- DotNetNuke - Data Access Layer Alternative - August 12th, 2008
- DotNetNuke - Modules - Linking within the module - August 14th, 2008
- DotNetNuke - Make Your Module Searchable - August 19th, 2008
- DotNetNuke Modules - Making Content Portable - August 25th, 2008
- DotNetNuke Modules - Exceptions the DNN Way - September 2nd, 2008
- DotNetNuke Modules - PortalModuleBase - September 4th, 2008
- DotNetNuke Modules - Inter Module Communication - September 9th, 2008
- DotNetNuke Modules - Finding The Page a Module is On - September 15th, 2008
- DotNetNuke Modules - Caching - September 17th, 2008
- DotNetNuke Modules - Module Settings - September 22nd, 2008
- DotNetNuke Modules - Retrieving Settings - September 24th, 2008
- DotNetNuke Modules - Advanced Architecture - October 20th, 2008
- DotNetNuke Modules - Creating the PA - October 30th, 2008
- DotNetNuke Modules - Automating the PA - November 5th, 2008
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!


May 26th, 2008 at 10:30 am
What you described is the official DotNetNuke way of doing data access but the framework does not require you to do it this way.
Currently I am using nhibernate in my module development.
The only requirement for building a module is, in your user control (ascx) that you inherit from PortalModuleBase. The data access and business logic layer (if you chose to have one) are up to you.
May 26th, 2008 at 10:43 am
Yes, you are correct. But, you get ahead of the lesson. This is a SERIES. And, to introduce the variations prior to teaching the foundational concepts is to confuse the student.
So, for those of you that are new to this, stay with me and ignore the comment from RipR for now.
May 27th, 2008 at 7:36 am
[...] .NET AnswersASP.NET, HTML, CSS, Visual Studio, CSharp, VB.NET and other programming items of interest. DotNetNuke Modules - Foundational Concepts [...]
May 28th, 2008 at 8:18 am
[...] Foundational Concepts [...]
June 6th, 2008 at 6:32 am
[...] Foundational Concepts [...]
June 18th, 2008 at 6:55 am
[...] Foundational Concepts [...]
June 23rd, 2008 at 6:37 am
[...] Foundational Concepts [...]
July 3rd, 2008 at 6:20 am
[...] Foundational Concepts [...]
July 3rd, 2008 at 6:27 am
[...] Foundational Concepts [...]