|
||||||||||
|
||||||||||
Model View Controller (MVC) | ||||||||||
|
||||||||||
Increases reusability by partially decoupling data presentation, data representation, and application operations. Enables multiple simultaneous data views. | ||||||||||
|
||||||||||
Facilitates maintenance, extensibility, flexibility, and encapsulation by decoupling software layers from one another. | ||||||||||
|
||||||||||
Structural Pattern | ||||||||||
|
||||||||||
Graphical, single-user applications are commonly organized around event-driven user interfaces. The developer draws a user interface with an interface building tool, then writes blocks of code that execute application actions in response to user input. Many interactive development environments encourage this sort of code structure, since they emphasize building the interface first and asking questions about functionality later. Some design methodologies emphasize starting with the user interface, which all too often solidifies into a final system design. The result is a program organized around user interface elements and user actions on those elements, with persistent data manipulation, application functionality, and display code completely intertwined. Code structured in the way described above can be successful for small, single-user systems whose functionality requirements change slowly over time. But such a structure is inadequate for larger, long-term, distributed projects for several reasons:
Distributed application designs can be improved by separating the data model from the various ways the data can be accessed and manipulated. The Model-View-Controller ("MVC") design pattern separates the application data from both the ways the data can be viewed or accessed, and from the mapping between system events (including user interface events) and application behaviors. The MVC pattern is composed of three component types. The Model component represents the application data, plus methods that operate on that data, with no user interface. The View component presents the data to the user. The Controller component translates user actions into operations on the Model. The Model, in turn, updates the View to reflect changes to data. The duties these component types perform, and the relationships between components, appear in Figure 1 below.
|
||||||||||
|
||||||||||
Use Model View Controller:
|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
|
||||||||||
Using MVC can have the following consequences:
|
||||||||||
|
||||||||||
MVC designs may encounter the following pitfalls:
|
||||||||||
|
||||||||||
The Java Pet Store sample application design is a MVC architecture. As shown in Figure 2 above, the JPS Model is composed of enterprise beans, the Views are implemented by a combination of JSP pages (written in terms of Web Tier JavaBeans components), and Controllers are Session beans and supporting controller classes.
Java Pet Store views are implemented in an HTML browser as JSPs,
based upon the master template jsp, located in the Java Pet Store
distribution in at
The Controller classes in the Web Tier include:
The Model classes in the Enterprise and EIS tiers include:
|