I have now been working with DotNetNuke 4.x for nearly a year (if you include the development time with beta versions of VS2005), and I thought that it would be useful to discus the many options for developing modules.
There has been much debate in the ASP.NET developer community at large, since the release of VS2005 (Visual Studio 2005) and VWD (Visual Web Developer), concerning the new development paradigm for Websites introduced in VS2005/VWD. As a result of demands from developers, Microsoft has recently added an add-on project type - Web Application Project or WAP.
Concurrent, with that debate, DotNetNuke Module Developers have debated, how they should their Modules. In this Blog, I hope to give you an idea of the various methods available.
1. App_Code or Dynamic Compilation
The first methodology is the methodology used in the DNN 4.x Starter Kits. This methodology basically extends the core Website project. Modules are developed by placing the user controls (and other content files in the DesktopModules/
[ModuleName] folder, and by placing the code files (Controller & Info classes and DataProvider classes) in the App_Code/
[ModuleName] folder.
The advantages of this method are:
- Inexpensive - this methodology is supported by VWD, which is a free download. At present this is the only development methodology supported by VWD.
- Simplicity, Ease of Use
- Speed (RAD), the dynamic compilation means that changes can be made quickly to any code file and the website just needs to be refreshed - no need to build as the code is dynamically compiled.
- As of 4.3.3 there is Increased support within the DotNetNuke core for this methodology
- The Starter Kit can be used to create the Module files as a start in development
- The Module Definitions module in the Host menu now allows a Dynamic Module to be "packaged" for release
The disadvantages of this method are:
- IP - this methodology exposes all the Intellectual Property, so is not really feasible for commercial developers
- Versioning - there is no single monolithic assembly for a Module so this provides a challenge for version control.
2. App_Code and PreCompile
VS2005 provides a Precompilation option. This feature is not available in VWD - although it can be carried out using the command-line aspnet_compiler (available in the .NET SDK).
This option, from a development perspective, is much the same as the previous option. However, this option does overcome both the disadvantages mentioned above.
There are two ways this can be done:
- Precompile the whole site (this is option is really only for those developers that are using DNN as a framework for a separate product, as all the code (core and modules) are precompiled into one or more assemblies.
- Precompile just the module. While precompilation, by defination builds the whole site, with the appropriate settings it is possible to identify the assemblies that are part of your module and package them as a module package, for distribution
3. Web Application Projects (WAP)
This approach which has been developed by
Bert Corderman and
Vladan Strigo so I won't go into too much detail here.
This approach uses the new Web Application Project add-in for Visual Studio (not supported by VWD). It follows fairly closely the approach used in DotNetNuke 3.x. To fully utilize this approach developers must be prepared (at the moment) to do some manual post build and packaging tasks, although Bert and Vladan are working on ways to minise this through the use of MSBuild scripts and Web Deployment Projects (WDP).
At this time, I would catagegorize these approaches as promising, but not for novice developers.
They do satisfy the need for IP protection and version control, but they do lose somewhat the speed and ease-of-use that the first methodology offers.
We have been working with both Bert and Vladan to make sure that the DotNetNuke core can provide tools for this approach.
4. Hybrid Approach using Class Libraries
This approach is a variation of the first methodology, and is an approach that I have developed for my own personal modules.
The big difference between this approach and the first approach is that the code files (Info, Controller, Dataprovider etc) are in a Class Library, rather than in App_Code.
It overcomes (to some extent) the disadvantages of the dynamic compile approach in that the Business Layer and Data Layer IP is protected, and version control is supported.
The code files for the user controls are still left in the website and so the advantages/disadvantages of the dynamic compile methodology still exist for this approach.
In one module I am developing, I have however, taken this approach to the extreme, as the only IP (other than HTML layout for templating) in the website is the following:
namespace MyNamespace
{
public partial class MyModule: MyModuleBase
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}
Thats it.
The reason why this works is that everything is funnelled through the MyModuleBase class.
I will be blogging in the future on this particular Module, as it develops a number of new and intersting ideas.