Java Reference
In-Depth Information
Consider a table. The concept of a table could be applied many ways depending on the needs of an application.
You can approach a table as a way to store data as a logical structure consisting of cells, rows and columns.
However, there are many ways to manage what is stored and how to represent that storage.
For storage decisions, a table might only allow some forms of data (decimal numbers) or it might permit special
operations (such as summing). It might behave like a database table, where rows represent records (groups of data
elements representing a single entity) and columns represent fields (a data type with consistent identity and
storage among all records). Alternatively, a table might have no restrictions on data storage and no special
significance attached to its rows and columns.
A table could also be presented in a number of ways in an application. It could be visually displayed as a grid,
graph, or chart. Or it might have no graphical presence at all. It could even use the same underlying storage to
supply information to more than one form of display, such as a grid that updates a chart when a user entered
values.
When there are so many possible ways to use a control like a table, you're presented with a dilemma. Clearly it
would be nice to be able to have some form of reuse, so you would not have to code every new table from scratch.
At the same time, it's hard to imagine just how to code a single component like this to be reusable. An
implementation that was too generic would require a great deal of work to modify each time it was used,
eliminating many of the benefits of reuse.
MVC offers an elegant alternative. It defines a complex element in terms of three logical subunits:
Model - The element's state, and means for changing the state
View - The representation of the element (visual or non-visual)
Controller - The element's control functionality, mapping actions on the view to their impact on the model
Many businesses today are based on the MVC pattern. Corporate management provides the model, establishing
the company purpose and setting up rules that govern how the business grows and functions. The sales and
marketing departments provide the view, representing the company and its products to the outside world. Finally,
product development and manufacturing represent the controller, taking information from the view and
translating it to actions that have impact on the model.
By breaking the element down in this way, each part can be treated independently of the others—or, at least,
almost independently. For the element to behave as a whole, each part must properly interface with the other two.
The view must be able to send messages to the controller and get information from the model in order to meet its
responsibilities. However, MVC offers a substantial benefit: it is possible to easily change parts of the component,
making a system using MVC extremely versatile. A table implemented this way can be converted from a grid to a
graph representation by changing the view.
The table example focused on a component, but you can apply the MVC pattern at the architectural level as well.
In an MVC component the model handles the component's state, the view represents the component's UI, and the
controller performs the component's event handling (or action mapping) functions. At the architectural level, you
can translate these features to a subsystem: the model actually represents the business model, the view is the
presentation of the model (the face of the data), and the controller defines business actions or operations.
MVC is a pattern that encourages good encapsulation. The principles of good object-oriented programming
recommend that you define elements in terms of their interface (how they interact with the outside world, other
objects, components or systems) and implementation (how they maintain state and function internally). MVC
supports this, since it explicitly breaks an element's responsibilities into:
Model - The implementation (state: attributes and internal behavior)
View - The outbound/outgoing interface (behavior: defines the services that can be used to represent the model)
Controller - The inbound/incoming interface (behavior: accepts request for updates on the model)
Implementation
