| A design pattern is a series of objects and object relationships that provide a proven, extensible solution to a particular software design problem. The Model-View-Controller (MVC) pattern is arguably the best known, most famous design pattern of them all. MVC was originally developed in the late 1970s at the Xerox Palo Alto Research Center (PARC). It was originally built to manage the GUI and user interaction on some of the first window-based computers (another innovation from the PARC ”in addition to Ethernet, local area networks, mice for input devices, and numerous other firsts). The design problem that MVC solves is that of simplifying three primary functions that are common in many applications: -
Maintaining the data in a back-end store or remote system -
Building the end-user presentation layer -
Maintaining the conditional logic that decides which screens are presented to the user, what happens when errors occur, and exactly how and when the remote systems are updated It is possible to combine all this processing into a single module and get a system to work. (In fact, a significant amount of early JSP development did exactly that!) Problems primarily occur when you try to perform maintenance on the code. In the case of JSP, this is compounded by the fact that the HTML designers who maintain the look and feel of the application are different people (and have different skill sets) from those who maintain the Java code that controls the processing. MVC addresses this problem by separating the code into three distinct areas: -
Model components that maintain data in a back-end store or remote system -
Views that build the end-user presentation layer -
Controllers to maintain conditional logic that decides which screens are presented to the user, what happens when errors occur, and exactly how and when the remote systems are updated MVC simplifies maintenance by keeping all this logic from becoming intertwined. It allows the details of each piece to be hidden from the others and reduces the coding linkages between them. This is how MVC provides a natural boundary between the people who write the Java and the people who maintain the HTML and presentation layer. A good example of this is in how MVC can simplify exception processing. Imagine that after a user logs in, you send a request to a remote system to fetch the user's customer information. What do you do if the remote system is unavailable? In normal JSP processing, it's common to embed logic at the top of your JSP file to detect this and change what you display to the user when the problem occurs. Using MVC, you can pull this logic out of the JSP page altogether: You create a page dedicated to presenting the error message and have the Controller determine which page to send the user to. If the remote system is available, the user gets the first page. If not, the Controller sends him to the error page. This approach to exception processing has multiple benefits. The first comes from the fact that, on many pages, multiple types of exceptions must be handled. Having a single JSP page that detects all possible errors and presents a different message when each error happens can become complicated fast. Moving that logic into a Controller makes things easier to maintain: The logic is maintained in the Controller, and only the presentation is maintained in the JSP file. Of course, another primary benefit of pulling the exception logic out of the main JSP pages is that it makes maintaining the JSP pages easier! These benefits really extend to all forms of conditional processing. Here are some other examples: -
If different Views are required depending on what data is retrieved from a database or remote system (for example, products on sale versus products not on sale), the Controller component can make the decision about which page to present. This keeps the logic out of the JSP page itself. -
If your site changes based on either the time of day or the day of the week, that logic is easy to implement in the Controller. You simply have the Controller check the date and forward the user to the appropriate page. -
Sometimes a data entry process can span several pages, some of which are optional. An example of this is signing up for insurance: You need to be shown the data entry pages for dependents only if you choose family coverage. In cases like this, MVC makes it easy to control the flow of pages that are shown to the user. Trying to embed this logic into the JSP pages makes things much more complex. THE ORIGINS OF THE MVC DESIGN PATTERN It is widely agreed that the MVC pattern was originally popularized in Smalltalk-80. MVC was used to manage the GUI relationship in some of the earliest window-based GUIs that were developed at the Xerox PARC. In researching the origins of the MVC pattern, I came across an archived posting from the Usenet group comp.lang.smalltalk from 1994. The posting read, in part: I thought you might be interested in a 'bit of history' on origin of the Model-View-Controller paradigm. Prof. Trygve Reenskaug is generally cited as being the creator of the MVC concept. He worked with the Smalltalk group at Xerox PARC as a visiting scientist in 78/79. During this stay at Xerox PARC he developed the MVC. I know him well and have talked to him about this. He confirms it, although stating that it was a collaborative effort at Xerox PARC. [...] Regards, Carl Carl P. Swensson, Senior Systems Eng. I then looked up Prof. Reenskaug's current home page on the Internet. In his biography, he lists the creation of "Model-View-Controller, the world's first reusable object oriented framework, in 1979" as one of his career accomplishments. I traded e- mails with Prof. Reenskaug while writing this book. He described his initial thoughts on MVC like this: My first idea was to separate presentation from information because the information structure is reasonably stable while the way we need to see it and manipulate it varies with the task. (This idea stems from around 1970 when I first became interested in distributed systems.) Prof. Reenskaug is now a Professor Emeritus from the University of Oslo in Norway. More recently, he contributed to the development of the Unified Modeling Language (UML) versions 1.4 and 2.0. The Object Management Group (http://www.omg.org) has honored him with a special award for his many contributions to the field of object-oriented design. | |
