Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Creating Testable Modules - The MVP Pattern

At the Open Force Europe conference in October I will be presenting a talk on Creating Testable Modules.  In this series of blogs I will be describing my learning experiences as I work my way through creating the examples and presentation material for the talk.

Phil Beadle has created a Project Template that you can download from the Forge, and I encourage you to work with this template if you are interested in building testable modules.

This blog is cross-posted from my personal site.  For those interested in viewing larger versions of the diagrams you can read the post there.

In the first part of this blog series on creating testable modules I described the need for supporting testability in DotNetNuke Modules. Lets take a look at our current typical N-tier design.

Figure 1 – Current Typical DotNetNuke Module Design Pattern


Figure 1 shows the current typical DotNetNuke Module Design Pattern. This is a fairly standard N-Tier design with 3 layers. The top – Presentation - Layer includes the User Control – both the ASCX file and the code behind file, the middle – Business - Layer includes the Controller class and the Info Class and the bottom – Data – Layer includes the Data Access logic.

The first problem with this design from a testability point of view is that it is not possible to isolate the Presentation Layer from the rest of the module, as User Controls don’t “exist” outside of the WebForm Framework. The Presentation Layer can be tested through the use of Web Automation Frameworks like Watin or WebAii but these, while useful are not Unit Tests in this scenario.

So we obviously need to modify our design pattern if we are going to Unit Test all aspects of our Module.

Model View Controller – MVC

The Model View Controller pattern has been around for some time, and was originally developed in Smalltalk to decouple the user interface from the internal application state and the business logic that manages that state.

Figure 2 – The MVC Design Pattern


There are three components: the Model, View, and Controller. The MVC pattern relies heavily on events so that the interface between the three components are not tightly coupled. In fact, only one object, the Model, is usually physically shared between the View and the Controller.

  • Model - The Model maintains state information and manages state persistence. It generates events when state changes.
  • View - The View displays state information. It monitors state change events and updates the user interface accordingly. It can query the Model for additional state information. The View does not change model state.
  • Controller - The Controller responds to View events (User Requests), which in web applications are usually REST-friendly URLs. It contains the business logic determining how to change the Model state based on View events. It can also query the Model's state. The Controller usually changes Model state through direct calls to the Model.

The MVC pattern is a popular web application design pattern and is the basis for the Ruby on Rails framework. There are a couple of MVC Frameworks for .NET including the new ASP.NET MVC Framework being developed by the Microsoft ASP.NET team, and currently in Beta.

However, MVC does not fit well with DotNetNuke which is principally written using Web Forms and is firmly tied to the Postback model, where a user interacts directly with the View.

Model View Presenter – MVP

The Model View Presenter pattern solves the issue with the MVC pattern that DotNetNuke does not support direct interaction with the Controller. In the MVP pattern the user interacts with the View through the normal ASP.NET WebForm Postback model  At the same time, this pattern also solves our problem with separating the responsibilities for view updating and event handling by using two separate classes.

Figure 3 – The MVP Design Patterns

MVP – Passive View MVP – Supervising Controller

The MVP design pattern has two major variants, which differ by how much the View interacts directly with the Model.

In the Passive View variant, the View is updated exclusively by the Presenter, whereas in the Supervising Controller variation the View interacts directly with the Model to do simple data-binding that can be defined declaratively. In this variant, the Presenter still handles the more complicated updates. This variant allows for the the modern use of data-binding controls, but is not quite as testable as the Passive View variant.

This is a very brief introduction to the MVP Pattern.  In the next blog I will show a simple example “Hello World meets MVP” of how the design pattern is used in practice.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?