Part 1 of this post will only briefly explain and tell what is MVC, its history and its derivatives. Demo source codes are provided at the end of each pattern. Part 2 of this post is still in writing and it will touch on the ASP.NET MVC 2 Framework.
This is my first post on ASP.NET MVC Framework 2 Preview 2 that ships with the .NET Framework 4.0 Beta 2. It will be a post of creating simple ASP.NET application using the MVC Framework 2 Preview 2 along with the Repository framework that I have posted previously in my blog. If you are interested to know one of the way of implementing Repository, Specification and Unit of Work with Entity Framework 4.0 Beta 2, you can click here to have a look and give me some comment and feedback. The sample project comes with this post may or may not work after the official release of Visual Studio 2010 and .NET Framework 4.0 on March 2010.
I would like to outline the prerequisites that you need to have in order to run the sample project attached with this post.
- .NET Framework 4.0 Beta 2
- Visual Studio 2010 Beta 2 ( I am using the Ultimate edition)
- SQL server 2005/2008 instance with any name you like as long as you change it to match it in the Web.config file of the web application project.
- Northwind database.
Before I go on with ASP.NET MVC Framework 2 Preview 2, I would like to clear up the confusion of all these buzzwords, MVC, Application Model MVC, MVP, Supervising Controller, and Passive View. If you are already familiar with these, then you can skip this post I. Of course, I will still welcome your feedback and comments. So, I would be able to know the crucial points and facts that I may have missed out.
MVC, Application Model MVC, MVP, Supervising Controller, Passive View
Without further ado, let look at what they are all about. In brief, they are architectural pattern used to isolate the business/domain logic from the user input and presentation. We gain the advantages of better separation of concerns. Better separation of concerns results in better reusability, better maintenance and easier testing.
In other words, MVC, MVP and Presentation Model are all GUI architectures. MVC comes first. MVC was one of the concepts originally found in Smalltalk. MVC was first described in 1979 by Trygve Mikkjel Heyerdahl Reenskaug who formulated the Model-View-Controller architectural pattern.
The MVP stands for Model-View-Presenter which is a derivative of MVC. It was in response to some shortfalls of the MVC. The Model-View-Presenter software pattern originated in the early 1990s at Taligent, which was the name of an object oriented operating system and the company dedicated to it.
Martin Fowler, later split the MVP into the Supervising Controller and Passive View through his retirement note for Model-View-Presenter at http://martinfowler.com/eaaDev/ModelViewPresenter.html. Supervising Controller and Passive View are similar to the MVP. They are different in the autonomy the view has in the view update logic.
Next is the Martin Fowler’s Presentation Model which pulls the state and behavior of the View into a Model class that is part of the presentation. One of the specialization of the Presentation Model is MVVM (Model View ViewModel) originated from Microsoft. It is targeted at the WPF (Windows Presentation Foundation) and Silverlight. MVVM clearly separate the responsibility of developer whose job is to purely write code and the UI designer whose job is to purely do the user interface design.
MVC (Model View Controller)
MVC make a clear division between the domain model and the presentation objects (view/controller). It is the business logic and data on which the business logic operates in general term. In a domain driven approach, it includes the domain model (entities and values objects), the Repository which mediates between the domain and the data mapping layer, the domain logic which are functional requirements of the business that add meaning to the domain model. (For e.g. calculating shipping taxes, loan interests and etc), the service facade which exposes the business logic as service so other applications can consume and it also abstract the other applications from the changes in the business logic as the service facade will make these transparent to them,and of course the persistence storage. Most of the applications persist the data in some form of storage such as database. This implies that the data access logic/layer also fall under the Model.
The view is some form of visualization of the state of the model. When we talk about the MVC in 80’s, it is the widget on the screen surface which can be a button, textbox, label and etc. It just concerns itself about only with the user interface in response to the update from the model. It neither cares about the presentation logic nor the processing of the user inputs.
The controller offers facilities to change the state of the model. In other words, it processes user inputs coming from input devices such as keyboard and mouse and transform them into the changes in the model. The controller will sometimes make logical decisions about the user input and update the view accordingly without involving the model. Here, I would like to stress again that we are talking about the widgets of 80’s which doesn’t know about mouse or keyboard inputs. The widget’s main purpose is to display the model’s data and the processing of the user inputs are the main purpose of the controller. So, the view and the controller form an indivisible pair. MVC requires each view has a controller and each controller has a view. Each view’s controller is dedicated to that view’s sole service.
Figure 1.0 shows the communication among the Model, View (widget) and Controller in the traditional MVC pattern in 80's
a. Controller receives input from user through keyboard or mouse.
If you look up the Wikipedia at http://en.wikipedia.org/wiki/Model_view_controller, you will notice that there will be reciprocal communication flow between the view and the controller. This is fine as the widgets (view) now are able to capture mouse and keyboard events since the inception of Microsoft Windows and its event driven programming.
The MVC explanation that follows after here is based on the general MVC diagram found in the Wikipedia.
The model, view and controller must communicate regularly. The model must notify the view about its state change. The view must register with the controller in order to receive user interface update event. The controller needs to update the model and the view in response to the user input.
To facilitate this communication, the model itself needs to keep a reference to the view instance which renders its state change in the form of user interface. Both the view and controller need a reference to the model instance respectively and reciprocal references to each other.
In MVC implementation, there may be multiple views per model, but there is exactly one controller for each view. Each controller serves only the view that it is dedicated to. The MVC pattern can be applied to a single user interface element like (text box, button and etc), to a group of user interface elements like (a user control which contains a number of other user interface elements), to an entire web page or winform or an entire application.
I will present the MVC clock application demo to show the implementation of the MVC pattern. Although, there is no single definite right way to implement MVC and there are lots of incarnations in the market now, the basic principle of the MVC pattern prevails.
The sample MVC clock application project that I have included here is rather a simplified implementation of the traditional MVC pattern in 80’s. In the traditional MVC pattern in 80’s, each view on the screen surface is a widget (label, text box, button and etc) and each of this widget has its own dedicated controller to form an indivisible view/controller pair. Thus, we will end up with a number of view/controller pairs for a simple application. The MVC clock application will target the entire clock screen (contains a number of text box, button, label and date pickers) as a view and a clock controller is dedicated to the clock view. I am not trying to have the MVC clock application to emulate the exact way the MVC pattern being implemented in the Smalltalk application in 80’s but just to give you an idea of the MVC principle. As you know the advance in technology will affect the way we implement certain things but the underlying principles still remain. For e.g. the widget (view) in the 80’s didn’t deal with the user input, instead it relied on its dedicated controller for the job. Whereas, the widget now can process inputs due to the advance in GUI technology.
Figure 1.1 depicts the MVC communication cycle for the MVC clock.
Figure 1.1 shows the simplest case of the MVC pattern used in the MVC clock application demo which you can download the code at the end of this discussion. It only has a single model, a single view and a single controller. However, it is very common for an application to have more than one view for a single model. For e.g. in the MVC clock implementation, we have only one single clock Model but we can have more than one view, probably we can add another analog clock view to the MVC clock project.
Class responsibilities in the MVC Clock
This section will touch on the MVC clock application demo.
Responsibilities of the Model (Clock)
The Clock model in our clock application defines methods specific to a clock. The methods include the SetTime() (to set the current time of the clock model) and SetAlarmTime() (to set the alarm time of the clock model). Controllers in the MVC must be custom written to manipulate the model. So, the controllers must know the SetTime() and SetAlarmTime() in order to manipulate the clock model.
In MVC, the model’s data can be changed externally by other classes or internally by its own logic. For e.g. the user might set a new time for the clock by clicking on the Set New Time button or it might be updated because, internally, it detects the passing of a second. In the clock application code, it tracks the passing of a second itself through a timer that fires every 1000 milliseconds.
The model must also provide a way for the views to register themselves with the model. In the event of model’s state change, the model can notify all the registered views about the changes. The clock demo application implements the notification through the Observer pattern. If you would like to know how this pattern is being implemented in .NET framework using the C# or other .NET language, please follow Microsoft’s pattern and practices at http://msdn.microsoft.com/en-us/library/ms998543.aspx.
The clock view instance will have to register with the clock model’s TimeChanged and AlarmTimeChanged event through the method call to RegisterModel() in the clock view’s constructor. The TimeChanged event will notify all the registered clock views when there is time change due to the user input or due to the internal tracking logic that detects the passing of a second. The AlarmTimeChanged will notify all the registered clock views when the alarm time changed by anyone of the user input from the view.
You will notice that the clock model is implemented as static class including all its members as static. I want to make it as global and available to any instance of the view at runtime. It also provides the simplest implementation in term of codes.
In the clock demo application, there is only one digital clock view but you can easily add in another analog clock view without making any changes to the model and the controller. What you need to do is just to hook up your analog clock view with the model and the controller.
Responsibilities of the View
The view will render the user interface to reflect the state change in the model. In our clock demo application, when the time changes, the model will notify the registered clock view. In response to the notification, the clock view will refresh its current time on the form.
Each view must forward the input requests/events to the controller. It should not process the input itself. For e.g. the user might change the current time through the date time picker and click the button for the Set New Time on the view, then the view merely forward the input information to the controller and the controller make change to the model through its methods.
Although the view cannot process the input and make change to the model, it can query the model for information when a notification is received from the model. For e.g. the view might invoke the GetTime() method on the model to determine the new time when it receives time change notification from the model. However, in the clock application demo, I have chosen to send the new time to the views directly in an TimeEventArgs object at notification time (Observer pattern). This is a more common approach and straightforward compared to having the view to query the model again when the time change notification is received.
You may find odd that if the user make changes in the view, instead of responding to it immediately, the view passes the input to the controller which can make change to the model through its methods, model notifies the view about the change and the view finally renders its changes to the user. It would be easier if all these steps are skipped. However, when the application become more complex, you will see the benefits of MVC pattern. For e.g. I have decided to add another analog clock view to the MVC clock demo application, the MVC pattern allows this to be done seamlessly because what I need to do is just to hook up my new analog clock view to the clock model and the clock controller. My job is done. Any changes in any of the clock views will be detected and reflected in all the views. I don’t even need to write any code to make the digital clock view to notify or update the analog cock view (or vice versa).
Besides, the logic is centralized in the model, which prevent code duplication and it allow us to add or remove views at runtime with minimal effort.
Responsibilities of the Controller
The controller listens for notifications from the view based on user input and translates that input into changes in the model. For e.g. when the user click on the Set New Time button in the view, the controller translates the input conceptually from “Set New Time” to the command on the model “Set model’s time to bla bla bla”.
There are cases when the controller doesn’t update the model directly but instruct the view to make changes to user interface by calling methods on the view. These changes are purely cosmetic and have no effect on the model. For e.g. Changing the time format from 12-hour to 24-hour format or vice versa. This is purely presentation concern and it doesn’t affect how the model stores its time.
After all the explanation of the MVC clock application demo, there are two key elements of MVC; Separated Presentation and Observer Synchronization . As the Smalltalk developed, these two key elements stayed.
Code Download: MVC clock application demo. (This application sample only requires Visual Studio 2008 that can open C# project. Right click on the above link and choose Save Target As. Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)
Application Model MVC
The original MVC used in the Smalltalk object-oriented programming language is not without faults. The MVC clock application example in the previous MVC section is just a simple way to demonstrate the MVC pattern and it only has very simple use cases which are very hard to find in the real life application. In our real life, User Interface gets more complex than we think especially in our current UI technology trend where it gets more complex, fancier, and user friendly.
To illustrate this point, let add another condition/requirement to the MVC clock application. If the time displayed is the alarm time set by the user then the displayed time is changed to some preset or user chosen color. It sounds simple at the first look. But the question is which element in the MVC is going to be responsible for this piece of presentation logic. Should this piece of logic be in the model, view or controller?
This shouldn’t fit into the domain logic object as the color used to display the alarm time is not part of the domain. It is certain that we can preset the color or allow the user to set the color through some mean of input and store the color value into a table for later references. Making the decision as to what color to preset or what color is available for the user input is certainly the domain issue. However, mapping that to the color for the displayed time is certainly the view logic issue. Where this piece of logic should be put? It is not a good idea also to put it in the text box that displays the time and we rather keep the text box generic and ignorant any kind of logic.
It is this kind of situation, the Application Model was invented. As the Smalltalk evolved, the folks behind Smalltalk faced this kind of problem and came up with a solution to it. It is called the Application Model MVC which is more inclined to the Presentation Model. It is introduced to shield the model and the view from the presentation logic responsibility. Thus, the controller and the view don’t access the model directly and don’t register with the model’s events. Instead, they access the Application model and register to its events.
”Smalltalk was originally developed by Xerox Parc labs and they span off a separate company, ParcPlace, to market and develop Smalltalk. ParcPlace Smalltalk was called VisualWorks and made a point of being a cross-platform system.” – Taken from the VisualWorks Application Model section under Martin Fowler’s GUI Architectures.
Under the Application Model MVC, the communication among the model, view, controller and application model for the MVC Clock application will look something like this;
c. Application model access the model and set the new alarm time through its method, SetAlarmTime().
d. The model raises the AlarmTimeChanged event so the application model will get notified about the change of the alarm time.
e. The application model delegate the event to the clock view.
f. The clock view queries the application model for the new alarm time and update its display to reflect the the latest alarm time.
c. Application model then fires the TimeChanged event and the AlarmSet event to notify the text box about the change of time and the alarm time is reached.
d. The text box in the clock view displays the latest time in response to the TimeChanged event and changes the color of the time with the blinking effect in response to the AlarmSet event send by the application model.
Based on the Figure 1.2 and Figure 1.3, we notice that the Application Model can’t access or manipulate the view directly. Instead, it relies on the Observer Synchronization to communicate with the view. The application model cannot simply change the color of the text box; instead it has to raise the AlarmSet event and has the view to respond to it.
There is one more benefit with the application model. You can use it to store the state or data related to the view.
MVP (Model View Presenter)
Dolphin Smalltalk’s MVP becomes the mainstream nowadays and IBM’s MVP is less appealing. In Dolphin Smalltalk’s MVP, there is more explicit discussion of how the presenter manipulates the view including information on what the presenter can do and can’t do. It is also easier to understand and straightforward.
Later, Martin Fowler retires the MVP pattern in favor of the Supervising Controller and Passive View.
Actually, the supervising controller described by Martin Fowler is oriented toward the MVP pattern employed in the Dolphin Smalltalk’s GUI framework where the MVP’s presenter replaces the application model in the Application Model MVC. In the Supervising Controller, the view handles a good deal of view logic and the presenter handles more complex cases.
In contrast, the presenter in the Passive View pattern has to do all the manipulation of the widgets leaving the View totally passive. The Passive View emerges later when people start exploring into TDD (Test Driven Development) in which the Passive View pattern makes the user interface of an application easily testable by introducing mock objects in the unit test.
Now we focus back on why the folks work for the Dolphin Smalltalk search for a better pattern to replace Application Model MVC. The controller used in the Application Model MVC is no longer applicable as there is no need for the controller to process the user inputs (capture keyboard and mouse events). With the introduction of Graphical User Interface operation system, Microsoft Windows into the market, a set of widgets are made available to construct user interfaces. At the same time they are able to capture the mouse and keyboard events leaving the controller needless.
The other usability problem with the Application Model is its inability to access the view directly despite the fact it is responsible for the view/presentation logic. It relies heavily on the Observer Synchronization to manipulate the view. For e.g. changing color of the text to show validation error, enabling and disabling the buttons and etc. Because of this, it will be better to break the observer synchronization to gain access to the view directly so the codes to perform all these will be less awkward.
So, the next will be the Supervising Controller as Martin Fowler describes it as the direction behind the Dolphin Smalltalk’s MVP.
Dolphin Smalltalk’s is similar to Martin’s Fowler’s Supervising Controller. So, I would explain both as one. As we know, in MVP we have Model, View and Presenter with the Presenter as the replacement of Controller in MVC. Below is the role for each of them.
The model in Supervising Controller has the same role in the MVC whose sole purpose is to represent the problem domain. It is completely ignorant of the User Interface and the presenter which is the intention of the pattern. Even if the view has communication with it through query, it will be loose coupling through the mean of Observer Synchronization.
It is the composition of widgets (text box, button and etc) on the screen. In MVC, each widget on the screen surface coupled with a controller. Since the controller is eliminated, the screen (web page/winform) is the view itself which has the responsibility to respond to the mouse and keyboard events and pass these input events to the presenter for further processing. In supervising controller, the view itself has some autonomy in User Interface update which can be defined declaratively.
It is in charge of the presentation logic. It commands the model to make necessary changes and change presentation according to the application rules. The presenter is allowed to communicate directly with the view so that it can make changes to the view. This is normally done through abstraction where the presenter keeps a private reference to the interface that the view inherits or implement. The interface, through which the presenter can manipulate the view. If we compare it to the Application Model MVC where the application model communicate with the view through observer synchronization, the presenter which can communicate directly with the view has eliminated the awkward code in the Application Model MVC. There is no special event needed for the view to handle as in the Application Model MVC. The rationale behind the Application Model MVC only communicates with view through loosely coupled events is it has unknown number of view/controller pairs for each widget added to the screen. Having this kind of relationship will shield the application model from frequent modification whenever there is new widget added to the screen.
Figure 1.4 shows the communication among the Model, View and Presenter for the Supervising Controller.
Let apply this pattern to our MVP (Supervising Controller) clock application demo for the scenario when the user change the alarm time.
Passive View is pretty much the same as Supervising Controller. The only different is that the view itself is totally passive as the name implies. The presenter in the Passive View handles all the view/presentation logic as much as it can no matter simple or complex cases. In this case, the view will become completely passive and it is no longer responsible to update itself from the state change in the model. Thus, the dependencies between the view and the model in either direction are totally eliminated as the presenter will assume all the responsibilities and roles between the view and the model in the Supervising Controller.
Passive view described by Martin Fowler look something much like the Application Model MVC. In Application Model MVC, the view interacts with the model through the application Model. In Passive View, the view interacts with the model through the presenter. The views in both patterns are shield from the model by application model and presenter respectively.
The force that drives Passive View’s popularity is its testability. Since all the presentation logic to update the view resides in the presenter, then the presenter is in charge of the entire workflow. The view can be easily mocked and the presenter can be effectively tested. We can test all the User Interface logic by just testing the presenter alone. By testing the presenter itself, we are actually testing the view indirectly and we only run a little risk by not testing the actual view itself.
Anyway, the decision to use Supervising Controller or Passive View is a judgment call. Both patterns provide testability and the driving issue is how much of the view update logic to leave in the view. By having all the view update logic in the presenter, there will be lot of effort being put in to write the presenters as all the simple view update logic needed to be included into the presenter as well. However, if codes simplicity is preferred over the testability, Supervising Controller will be a better choice.
Figure 1.7 shows the communication among the Model, View and Presenter for the Passive View.
c. Presenter updates the model with the new alarm time through the model’s SetAlarmTime method.
d. The model’s raise AlarmTimeChanged event so the presenter will be notified of the change in the alarm time.
e. The presenters update the view directly through the view interface’s AlarmTime to reflect the latest alarm time in the view.
b. Presenter queries the model for the latest alarm time through model’s GetAlarmTime() method. It checks whether the current time is equal to the alarm time.
c. The presenter changes the view directly to reflect the latest state change in the model through the view’s interface IsAlarm.
The two clock application samples I have enclosed with the Supervising Controller and Passive View patterns are desktop (winform) application. So, we can have a state full model to allow direct synchronization between the model and the view and presenter in Supervising Controller, and direct synchronization between the model and the presenter in Passive View.
In web application (ASP.NET), due to the stateless nature of the web, it rarely make sense to use the observer synchronization between the model and presenter or model and view.
This would be the end of this post. I haven’t touched on the Presentation Model which I have mentioned at the beginning of this post. I will leave it to my different post when I plan to write some stuff on the WPF. The MVVM (Model View ViewModel) is a derivative of Presentation Model and it is being employed in the Composite Application Block for WPF and Silverlight (PRISM).
My post 2 will surface within this month if I have not had much of the personal stuff to attend to.
See you in my next post.
Bye and stay tune...
- Official Microsoft ASP.NET -> http://www.asp.net/mvc
- Martin Fowler’s GUI Architectures -> http://www.martinfowler.com/eaaDev/uiArchs.html
- Web Client Software Factory’s View Testability Guidance -> http://msdn.microsoft.com/en-us/library/cc304760.aspx