DNN Custom Module Best Practices

DotNetNuke Custom Module is the extensibility to the DotNetNuke features and functionalities. It’s always Developer’s Experience and Skill that matters the way it gets Designed/Developed. It’s significantly affecting to DNN Portal performance and interactions where webmasters have interest.

DNN Custom Module Architecture

DNN Custom Module Architecture

DNN Custom module should have a specific architecture so once it gets integrated/installed at DNN Framework it communicates correctly as a part of functional extension logic effectively with the DNN Framework. DotNetNuke Custom Module should have the three-tier architecture where Database layer, business logic layer, and interface layer should be separated.

In the early days of DNN when DNN Custom module development was the lengthy process, I remember we had a checklist to configure every new DNN Module to set-up and configure the development environment so that it can correctly step into code through visual studio debug feature. Visual Studio template is the great addition. Visual Studio Project Template becomes very handy. We have various versions of DNN Custom Module template where it available at DNN Store and Visual Studio Template Gallery. Experienced developer prefers to have their own customized/modified DNN Module Template so every piece of code can have same signature and pattern along with similar naming convention.

Here are the several Best Practice tips for the DotNetNuke Custom Module Development.

PortalModuleBase: It’s the DnnController base class provides access to the PortalSettings object, every DNN module has a feature to set configurations through Setting page for the instance of the Module.

Portal Module Base allows two types of Settings, Module settings, and Tab-Module settings.  When you use Add Existing Module on another page Module settings will be the same but not Tab-Module Settings. The developer has to decide and use the feature wisely.

SQL Scripts: Multiple DNN Instances can be installed at the same/single database with object qualifier. It’s required to pack DNN Install package SQL Script with the object Qualifier and database Owner which is the token configured at The Web.Config file while first time DotNetNuke was configured.

Module.CSS: DNN Custom Module Cascading Style should be defined at Module level through module.css. DotNetNuke has a bunch of CSS layers where Container, Skin, Portal level style can override the effect/layout of Style so take care to define Style class name carefully and use Important keyword wisely to adjust and control the layout with multiple skins.

Session Variables: Session variables can cause issues when running in web farm scenarios, avoid using Session variable. It also reduces the performance.

NavigateURL: helps to navigate among module level internal controls like settings, Edit. It helps to pass parameters with the moduleid or tabid and it keeps URL related global settings for the URL type configured.

We need the user to stay logged in; the URL they browse to has to have a mangled URL. It means you must use relative links to stay logged in.

Localization.GetString: It’s necessary to code such a way to read the resource files where Name and help content/text for the UI controls get defined. It may happen for the future the same DNN Custom Module need to be a multilingual and in such scenario, using resx files located under “App_LocalResources” and GetSetting of Localization becomes very helpful.

MS Build: It’s great enhancement to make DNN Module Packaging automated. If developers use MS Build script it makes sure all the necessary files included at the Install package along with validated DNN file settings and configurations.

IActionable: Allows DNN Custom module to define the Module Menu to navigate among the DNN Custom Module Controls. A number of controls can be designed and manage the logic to perform data operations separated to user controls with overriding the functionality of DNN Framework.

ISearchable: Allows module developers to implement a common collection of items that DotNetNuke can index and provide via the search results module.

IPortable: Interface to allow DotNetNuke Custom modules content to import and export.

IUpgradeable:  Allows module developers to apply code during install/upgrades based on the module version, like if installed module getting updated then specific logic can be implemented for the Upgrade patch version.

ModuleSearchBase: Custom Module Content can be indexed for the Search Result by DNN Framework.

We at DnnDeveloper.In is very Experienced and Skilled with DNN Custom Module development, we follow the best practices to get best out of DNN Framework. Please contact us @ Sales@DnnDeveloper.In for the any DotNetNuke Custom Module development requirement.


Leave a reply