Recently, I was at Half-Price Books where Pro ASP.NET 4 in C# 2010 by Matthew McDonald, et al was sitting (at more than half-off the retail price, by the way). I started to thumb through the book and in Chapter 12, we learn how to build a simple file browser web application. The code was simple enough and I started thinking about the MVC pattern and how I could adapt this example to use MVC. I conceptually understand the MVC pattern and why it helps. However, I do have questions and concerns about it, mostly around the model. Isn’t it just the business logic layer or a data layer? In other words, to me it didn’t seem like it was directly tied into the presentation. Why does it specifically need to be part of this pattern? It seems to me that the view and controller should be sufficient and the model seemed extraneous. Second, the controller is just a forwarder for the view. Why couldn’t the controller do more? These questions puzzled me the most about the MVC pattern. I put the book back and continued browsing the shelves.
Must have been my lucky day because also on the shelf was Microsoft .NET: Architecting Applications for the Enterprise by Dino Esposito et al. I had borrowed it from the corporate library several times for reference while doing design work. I never looked at Chapter 7 in detail which talks about the presentation layer although I knew it mentioned the MVC pattern. I found a chair and started reading. I never realized that this pattern had such an interesting history. I was also gratified that my MVC questions were answered.
The Original MVC Paradigm
Esposito takes the reader through a history of MVC starting with the original MVC paradigm mentioned in a MVC 1979 paper. Esposito places emphasis on the term “paradigm” as it implies a construct that is amenable to modification and extension as opposed to a pattern which is more firmly rooted. This is probably the reason why there are so many variations of MVC. Figure 1 shows the original MVC pattern as discussed in the paper. The paper refers to the model, view, and controller as the “MVC triad.”
The green lines show the typical sequence of operations with an optional operation in purple. Esposito mentions that the main issue with the original MVC is that the model can communicate with both the controller and the view. In a layered design, lower levels should only communicate with the layer directly above it. In the original MVC, this is not the case. A second issue is that the controller is dependent on a concrete implementation of the view. This makes it difficult for an application to support multiple views or change the view entirely (say from an ASP.NET form to a Windows form). The same holds true for the dependency on the controller on a concrete model implementation.
The Model View Presenter Pattern
The coupling issues inherent in the original formulation of MVC, led to the formation of the Model View Presenter (MVP) pattern. This pattern is first mentioned in this paper. This pattern is a descendant of MVC but gives the controller more power, thus eliminating the coupling of the model to the view. The controller becomes the central figure in the pattern. The view becomes “dumber” because it does not have to interact with the model. The upshot of all this is that the solution becomes more testable. Now that the UI contains code that simply operates on visual elements, the need for automated testing in the view is reduced. The automated testing can now be focused solely on the controller. A second benefit is that the view can be changed (say from a ASP.NET form to a Windows Form) without changing the controller code. Or the same application can provide multiple views based on the same controller. This is possible because the controller is not dependent on the concrete view but on an interface the view exposes. From this, you can see another testing benefit – the view can be mocked. The same holds true for the dependency on the controller to an interface exposed by the model. Figure 2 shows the MVP pattern in action. Yes, the controller becomes more complex but the tradeoff being simpler testing and more flexibility to application changes makes up for it.
Notice the controller is now called the presenter presumably due to its expanded responsibilities. It is also dependent on interfaces exposed by the view and model rather than concrete implementations. Esposito coins the term “presenter-first development” for this characteristic. This makes the view and model amenable to mocking, facilitating automated testing.
So What of the Model?
By this time, my questions concerning the model have been answered. Yes, the model in enterprise applications is the business logic layer (or a data layer for simpler applications). It is not directly related to presentation. MVP also addresses my other concern about the controller playing a larger role and eliminating the dependency between the view and model. Indeed by abstracting the model through an interface, who cares what the model really does now right? The same holds true for the view.
The View and Data Binding
ASP.NET, WPF, and Windows Forms offers a great data binding infrastructure that makes it easy for the presenter to update the view. The question is should the view contain the data binding code at all? The benefit of MVP is a “dumb” view. Does data binding code make it smarter and does that impact testability. In my opinion, this is a judgment call. Data binding certainly reduces complexity. If you are comfortable with not testing the data binding infrastructure then put the data binding code in the view. However, if you feel the need to put data binding logic in the presenter, then put the code in the presenter. Fowler calls these MVP variations Supervising Controller and Passive View respectively. In the case where you need to have complex logic that data binding doesn’t provide, then my opinion is to put that code in the controller where it can be tested.
Presentation Model is a variant of MVP. It is used in WPF and Silverlight applications. The model in this pattern plays a key role. The model is not the business logic or data layer as it is in MVP. Rather, it contains the state of the view. It is through the model that the view is updated. The view in Presentation Model is “dumb.” It only contains logic to render the controls. The controls’ properties are bound to properties on the model. Figure 3 shows Presentation Model in action. Note that the view and model data binding is bidirectional which WPF supports.
Esposito and Fowler really clarified MVC for me. The driver for the original MVC pattern was separation of concerns. As applications became more complex, MVP was devised to address testability concerns. Presentation Model is a further refinement that incorporates bidirectional data binding which facilitates testing and reduces some of the complexity of implementing a supervising controller. My key takeaway is that as long as the solution you’ve come up with meets the customer’s requirements and is testable, what patterns you use or don’t use is not important.