Thus far we have spent a great deal of time examining patterns that are used to solve local problems, that is; problems that span only a handful of classes and not the whole application. These patterns have been narrow in scope. They frequently only relate to two or three classes and might be used but a single time in any given application. As you can imagine there are also larger scale patterns that are applicable to the application as a whole. You might think of "toolbar" as a general pattern that is used in many places in an application. What's more, it is a pattern that is used in a great number of applications to give them a similar look and feel. Patterns can help guide how the whole application is assembled.
In this chapter we're going to look at a family of patterns which I've taken to calling the MV* family. This family includes MVC, MVVM, MVP, and even PAC. Just like their names, the patterns themselves are pretty similar. The chapter will cover each of these patterns and show how, or if, we can apply them to JavaScript. We'll also pay special attention to how the patterns differ from one another. By the end of the chapter you should be able to thrill guests at a cocktail party with an explanation of the nuances of MVP versus MVC.
The topics covered will be as follows:
- History of Model View patterns
- Model View Controller
- Model View Presenter
- Model View ViewModel
Separating concerns inside an application is a very important idea. We live in a complex and ever-changing world. This means that not only is it nearly impossible to formulate a computer program which works in exactly the way users want, but that what users want is an ever-shifting maze. Couple this with the fact that an ideal program for user A is totally different from an ideal program for user B and we're guaranteed to end up in a mess. Our applications need to change as frequently as we change our socks: at least once a year.
Layering an application and maintaining modularity reduces the impact of a change. The less each layer knows about the other layers the better. Maintaining simple interfaces between the layers reduces the chances that a change to one layer will percolate to another layer.
If you've ever taken a close look at a high quality piece of nylon (from a hot air balloon, parachute, or expensive jacket) you may have noticed that that the fabric seems to form tiny squares. This is because, every few millimeters, a thick reinforcing thread is added to the weave to form a crosshatch pattern. If the fabric is ripped, then the rip will be stopped or at least slowed by the reinforcement. This limits the damage to a small area and prevents it from spreading.
Layers and modules in an application are exactly the same: they limit the spread of damage from a change.
In the early chapters of this book, we talked a bit about the seminal language, Smalltalk. It was the language which made classes famous. Like many of these patterns, the original MV* pattern, Model View Controller (MVC), was used long before it was ever identified. Although difficult to prove it seems that MVC was originally suggested in the late 1970s by Trygve Reenskaug, a Norwegian computer scientist, during a visit to the legendary Xerox PARC. Through the 1980s the pattern became heavily used in Smalltalk applications. However, it was not until 1988 that the pattern was more formally documented in an article entitled, A Cookbook for Using the Model-View-Controller User Interface Paradigm by Glenn E. Krasner and Stephen T. Pope.