Building testable modules using Model-View-Presenter (MVP) pattern of development provides many of the benefits attributed to the MVC pattern which has become very popular as an alternative approach to ASP.NET development. The MVP pattern retains most of the benefits of the webform framework of rich controls usually through View (User Control page) which receives control from the WebForms Framework to pass “control” to a Presenter class. In this blog post, let’s take a look at creating testable modules using varied patterns.
Typical N-Tier DotNetNuke Module Design Pattern
The above figure depicts a typical N-Tier DNN Module Design Pattern with three layers – Top layer is Presentation Layer which includes the user control (both the ASCX file and the code behind the file), middle layer is Business Layer which includes the Controller class and the Info Class and the botoom layer is Data Layer which includes the Data Access logic.
From a testability point of view the problem with this design pattern is that it is not possible to isolate the Presentation Layer from the rest of the module. The reason behind this is that the user controls does not exist outside of the WebForm framework. The PL can be tested through the use of Web Automation Framework like Watin or WebAii but these are not useful the unit tests in such a scenario. So, we need to modify our design pattern if are going to unit test all the aspects of our module development.
Typical MVC Design Pattern
The MVC pattern is a popular web application design pattern and is quite famous among the developers. It contains 3 components: the Model, View and Controller. The MVC pattern mostly relies on events so that the interface between the three components are not tightly coupled. In fact only the Model is usually shared between the View and the Controller. However, MVC does not fit well with the DNN which is principally written using Web Forms and is firmly tied to the Postback model where a user interacts directly with the View.
Typical MVP Pattern
The Model View Presenter design pattern solves the problem with the MVC pattern that DNN does not support direct interaction with the Controller. In the MVP pattern the user interacts with the View through the ASP.Net WebForm Postback model and this pattern solves the problem with separating the responsibilities for view updating and event handling by using two separate classes.
The MVP design pattern has two major variants. In the Passive View variant the View is updated by the Presenter whereas in the Supervising Controller variation the View interacts directly with the Model to do data-binding that can be defined declaratively. In this variant, the Presenter handles the more complicated updates and allows for the the modern use of data-binding controls that is not quite as testable as the Passive View variant.
This is just a brief introduction to the various testing scenarios using varied design pattern. Have more to share? Then leave your replies in the comment box below…!