Java Reference
In-Depth Information
Table 8-2.
Components of an MVC Architecture
Component
Role
Model
The Model is the interface to the remainder of the application. It provides a
consistent way for the Controller(s) to access and/or modify data, and returns
data in a specified format. It is not uncommon for the Model to incorporate
other design patterns—for example, the Façade pattern to hide low-level
application details; the observable side of the Observer pattern to provide
automatic updates to view(s); the Singleton pattern to ensure that only one
instance of the model can exist; and so on.
View
The View is the actual visual representation of the data. The underlying system
may store data in a number of ways, but it is the function of the View to interpret
and transform the system data into an appropriate format. Some appropriate
presentation formats may include an HTML page, a PostScript document, or the
GUI of a Java application. No matter what type of data display is chosen, the fact
remains that the View is solely responsible for transforming the system's internal
data format into the presentation format. The View must also allow for human
interaction. The user may click a button in the GUI interface, and the View must
handle and dispatch that action. This translates into a call to the Controller. It is
important to realize that a View does not necessarily have to correspond to a
screen layout—it is also possible in a business-to-business (B2B) scenario that
the View may be an XML document that is being sent to a remote application.
Controller
The Controller is the mediator between the data and presentation portions of
an application. The View calls the Controller and instructs it to execute a certain
action. The action may require data passed from the View, or it may pass data
back to the View. In any case, one thing is certain: All interaction between the
data tiers and the presentation tiers must occur through the Controller. To pre-
serve the high level of abstraction the MVC allows, the View must never bypass
the Controller and communicate directly with components below it. For
instance, the View should never call the database directly and tell it to execute
a query. Instead, the View should call the Controller and instruct it to call the
database component.
When you get to the restaurant you look at the menu and decide the salad looks really
nice. So you ask the counter person for a salad and a milk shake. That individual goes to the
kitchen, collects your food, and returns it to you.
This is a pretty common scenario, but it is a perfect representation of the MVC pattern.
Let's break down the main actors in this scenario and map them to their equivalents in the
MVC pattern.
The View in this example is the menu being presented to you. The type of View may
vary—you may be inside the restaurant looking at a menu in your hands, or you may be in
the drive-through looking at a menu on the wall. The same information is presented in either
View, but it might be presented in different formats—a paper menu for patrons inside the
restaurant or a painted menu for those in the drive-through.
The Controller in this scenario is the counter person who takes your order. That person
acts as the buffer between you and the actual operations of the fast-food restaurant. The
counter person takes note of the meal you request, and arranges for it to be provided to you.
