DotNetNuke, commonly known as DNN, is an open-source web content management system that utilizes Microsoft's .NET framework. It's a popular choice for building dynamic and feature-rich websites, with one of its biggest advantages being its extensibility. One way to extend DNN is by creating custom modules that can be added to a DNN website to provide additional functionality. In this article, we will explore the different module architectures available in DNN and discuss their respective advantages.
The default functionality of DotNetNuke can be improved by including third-party modules. Modules can be acquired through an already-existing module store, produced internally or by outside writers, and they can offer specialized functionality. Although the DNN framework offers fundamental functions like security, user administration, and content management, modules are utilized to customize a website to fit particular deployment requirements.
A group of volunteers maintains a number of important modules that are part of the DNN core distribution. These modules give you the tools you need to build a custom web application, an intranet, an e-commerce system, or a public website. Most projects have moved from the DotNetNuke Community Forge to GitHub in recent years.
In DNN, web pages contain skins that specify different areas of a page and their design. Page editors can add modules or site administrator-provided extensions to these skins. To specify which user groups can read or edit each item, modules, and pages can inherit access rights or define their custom access permissions.
Several methods can be used to generate modules. Compiled modules are often created in C# or VB.NET and follow the Web Application Project concept. Razor modules employ a scripting language written in C# or VB.NET, whereas dynamic modules use the Web Site Project paradigm.
About DotNetNuke Module
A common DNN webpage is composed of both page elements and content blocks. Page elements, which may include the site menu, login control, and search bar, are pre-built components that come packaged with the DotNetNuke theme. On the other hand, modules are responsible for managing the content blocks on the DNN page.
Modules serve as fundamental components that expand the functionality of DNN, allowing users to browse, generate, and modify content. Every administrative capability in DNN is built on the framework of modules.
Two possible approaches include manual development, where the entire module is constructed from scratch, or a more automated approach where a template or automation tool is used to create the basic module structure.
Common DNN Module Features
When you develop a custom module for DotNetNuke, the framework's predefined set of features is automatically applied to the module if the developer has correctly defined and utilized those features.
Module Action Menu: Standard functionalities such as module deletion, printing, content import/export, and content placement are available through the module action menu. The menu items are generated dynamically, depending on the features of the module and the settings of the site.
IPortable to import and export, IActionable for navigation to other controls, ISearchable to enable the search syndicate feature, and the Help link that explains the user guide document
Module Settings: Setting objects for various entities, such as host, portal, tab, tab module, and module, is incorporated in DNN. DNN handles the storage and retrieval of these settings to streamline module development. These common settings may need to be accessed to determine which features of the module to enable. In addition to the common settings, it is possible to create custom settings and a corresponding user interface to manage them.
Packaging: In order for modules to be shared with other DNN instances, they need to be packaged in a standard format. These packages are essentially .zip files that come with a custom DNN manifest. The manifest, which is an XML file with a .dnn extension, outlines how the various components of the module are to be installed and accurately deployed.
Security: At DNN, a role-based access control system is in place to provide precise control at the site level, page level, and module level. It is possible to enhance this system and achieve greater granularity in permission settings at the module level.
Containers: Each module on the page in DNN is enclosed within a container. This container serves the purpose of not only determining the appearance of the content blocks, but also offering user interface elements to control the module, such as the module title, the module action menu, and the action links.
DNN Module Layers
Even though each module has its own unique features and functions, there are specific architectural components that are shared among them. Typically, DNN modules are constructed with n-tier architecture, regardless of whether they are Web Forms, MVC, or SPA modules. As a result, most of these layers will need to be implemented within your module.
Data Access Layer: There are three Data Access Layer (DAL) frameworks that are supported by DNN: DAL, DAL+, and DAL2. Although they differ in name, they all rely on the same underlying provider model. This allows DNN to be compatible with a variety of database management systems.
Caching Layer: Among the various actions performed by a web application, accessing the database is typically one of the slowest. This is often due to the fact that the data is stored in a format that is different from the format in which it is used. Additionally, applications may perform complex queries to filter the data and then modify the results before using them. Furthermore, if the database is not located locally, the query can take even longer depending on the network speed. Compared to using an in-memory cache, performing database queries is significantly slower, often by orders of magnitude.
Business Logic Layer: The majority of business rules are typically incorporated into the business logic layer. This layer is responsible for a variety of tasks, ranging from basic data validation to orchestrating complex workflows across numerous back-end systems. Additionally, the business logic layer coordinates interactions with the caching and data access layers.
DNN offers a range of APIs that can be used for handling common tasks, such as managing application security, storing files, organizing lists, logging events, and conducting full-text searches. These APIs are fully abstracted and extensible, enabling developers to concentrate solely on the business rules that are pertinent to their particular module.
Service Layer: DNN offers a service framework that developers can use to quickly and easily define web services. The Service Framework includes built-in access to frequently used DNN entities within service methods. This allows services to determine important details, such as the site being accessed, the user making the request, and the module that is handling the request. Additionally, web services can be secured by specifying which users and applications are authorized to access the service endpoints.
Presentation Layer: At the heart of the presentation layer lies the module control, which is responsible for managing each unique view of a module. In the DNN manifest, every module control is registered to ensure proper functionality.
DNN APIs make it easy to access any module control, thereby simplifying view management within your module. However, modules also have the option to implement their own view dispatch methods in order to customize when and how specific views are displayed.
In the case of Web Forms modules, the primary view component is an ASP.NET user control, known as a module control within DNN. For MVC and SPA modules, DNN has broadened the definition of module controls to better accommodate their differing view-rendering pipelines.
Web Forms Architecture
The Web Forms architecture is the most common module architecture in DNN. It is based on the ASP.NET Web Forms model and uses server controls to render the module's UI. This architecture is easy to learn and requires minimal coding knowledge, making it an excellent choice for beginners. Web Forms modules can also be easily customized using CSS and JavaScript. However, this architecture can become complex and hard to maintain as the module's functionality grows. Additionally, the server control model can lead to slower page rendering times.
When developing a module, the first step is to choose the development framework and approach.
- Web Forms. This traditional framework creates DNN modules that use controls based on ASP.NET WebForms.
- This framework (introduced in DNN 8) uses the ASP.NET MVC framework.
- This family of frameworks builds modules using plain HTML, JavaScript, and CSS. You can use any SPA framework.
MVC Architecture
The data model, user interface, and control logic of an application are divided into three independent parts using the Model-View-Controller (MVC) design, which is a common web development paradigm. Compared to Web Forms, this design is more flexible and modular, allowing for the creation of more complex modules. The MVC architecture is also renowned for its testability, which can aid programmers in finding and resolving problems more quickly. MVC, however, may be more difficult for beginners to grasp and requires more code experience.
SPA Architecture
A more recent module architecture called a single-page application (SPA) enables quicker page rendering times by using client-side JavaScript to render the user interface. Because the application does not require a full page reload while browsing between pages, SPAs can also offer a more seamless user experience. The modules that need a lot of interactivity or have a lot of data to handle are best suited for this architecture. To manage data retrieval and manipulation, SPA modules may need additional server-side APIs and can be more difficult to design.
Razor Page Architecture
Added in DNN 9.4.0, Razor Pages is a modular architecture that makes use of the ASP.NET Core Razor Pages framework to make it possible to create modules quickly and easily using the Razor syntax. This strategy is simple to understand and perfect for those familiar with Razor syntax. Furthermore, Razor Pages modules have improved efficiency and are simple to customize using CSS and JavaScript. Due to its lack of MVC architecture's flexibility, it might not be the best choice for complicated modules.
Web API Architecture
The Web API architecture's RESTful API makes it easier for modules or external systems to communicate with one another, especially when one or more of the modules needs to access external data or provide data to other modules. It is possible to mix this architecture with other module architectures, and it offers a lot of flexibility. However, because the implementation of this architecture requires a solid grasp of RESTful APIs, it might not be suggested for beginners.
In conclusion, the experience of the developer and the module's requirements determine the module's design in DNN. Web forms are a great option for novices or modules that just need a little customization. MVC is a more flexible and modular architecture that works best for more complex modules. SPA is a more recent architecture that offers better performance and interaction but may necessitate more in-depth programming knowledge. A Web API is a RESTful API that gives modules a method to connect with one another or with external systems, and Razor Pages offer a quick and easy way to develop modules that employ Razor syntax. Whatever architecture is selected, DNN's extensibility guarantees that developers can construct unique modules to match their unique needs.
The DNN Manifest Schema
The DNN manifest is an XML file, typically named after the extension package (e.g. MyDNNExtension.dnn), that specifies how particular files within the package should be processed during installation.
Only files that are explicitly declared in the manifest will be installed. Files that are contained within a zip file specified in the (component type="ResourceFile") do not need to be individually listed. If any files specified in the manifest do not exist, an error message will be generated.
The manifest file extension must be ".dnn". It is also possible to include the DNN version in the file name, such as "MyDNNExtension.dnn7".
To include the manifest file in the package, it should be saved in the base folder of the package and included when zipping the package files.
At DNNDevelopers, we have invested years in identifying the ideal approach, tools, and practices for maximizing the potential of the DNN Platform. We have developed and implemented exceptional functionalities with the highest quality and industry standards. If you require assistance in designing a solution for your business needs, we are prepared to deliver the best results.
DotNetNuke offers different techniques for module development, including compiled modules, dynamic modules, and Razor modules. Compiled modules use the Web Application Project model and are typically written in C# or VB.NET. Dynamic modules use the Web Site Project model, while Razor modules use a C# or VB.NET scripting language. Each technique has its advantages and disadvantages, and choosing the appropriate method depends on the specific needs of the project. Overall, the flexibility of module development in DNN allows developers to create unique modules and extend the functionality of the platform to meet various business needs.