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

By breaking the element down in this way, each partAcanMbe treated independently of the others—or, at least, almost independently. For the element to behaveEas a whole, each part must properly interface with the other two. The view must be able to send messagesTto 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

The MVC component diagram is shown in Figure

TEAM FLY PRESENTS

141