Tecnologia

Java SE Application Design With MVC
By Robert Eckstein, March 2007
Articles Index
Contents
- What Is Model-View-Controller (MVC)?
- Interaction Between MVC Components
- Modifying the MVC Design
- Using the Modified MVC
- Issues With Application Design
- Common Swing Component Listeners
- Conclusion
- For More Information
What Is Model-View-Controller (MVC)?

If you've programmedwith graphical user interface (GUI) libraries in the past 10 years or so, you have likely come across the model-view-controller
(MVC) design. MVC was first introduced by Trygve Reenskaug, a Smalltalk developer at the Xerox Palo Alto Research Center in 1979, and helps to
decouple data access and business logic from the manner in which it is displayed to the user. More precisely, MVC can be brokendown into three
elements:
Model - The model represents data and the rules that govern access to and updates of this data. In enterprise software, a model often serves as a
software approximation of a real-world process.
View - The view renders the contents of a model. It specifies exactly how the model data should be presented. If the model data changes, the view
must update its presentation asneeded. This can be achieved by using a push model, in which the view registers itself with the model for change
notifications, or a pull model, in which the view is responsible for calling the model when it needs to retrieve the most current data.
Controller - The controller translates the user's interactions with the view into actions that the model will perform. In a stand-alone GUI client,user
interactions could be button clicks or menu selections, whereas in an enterprise web application, they appear as GET and POST HTTP requests.
Depending on the context, a controller may also select a new view -- for example, a web page of results -- to present back to the user.
Sun BluePrints Catalog

Figure1. A Common MVC Implementation
Interaction Between MVC Components

This sectionwill take a closer look at one way to implement Figure 1 in the context of an application in the Java Platform, Standard Edition 6 (Java SE
6). Once the model, view, and controller objects are instantiated, the following occurs:
1. The view registers as a listener on the model. Any changes to the underlying data of the model immediately result in a broadcast change notification,
which the viewreceives. This is an example of the push model described earlier. Note that the model is not aware of the view or the controller -- it
simply broadcasts change notifications to all interested listeners.
2. The controller is bound to the view. This typically means that any user actions that are performed on the view will invoke a registered listener method
in the controller class.
3. Thecontroller is given a reference to the underlying model.
Once a user interacts with the view, the following actions occur:
1. The view recognizes that a GUI action -- for example, pushing a button or dragging a scroll bar -- has occurred, using a listener method that is
registered to be called when such an action occurs.
2. The view calls the appropriate method on the controller.
3. The controlleraccesses the model, possibly updating it in a way appropriate to the user's action.
4. If the model has been altered, it notifies interested listeners, such as the view, of the change. In some architectures, the controller may also be
responsible for updating the view. This is common in Java technology-based enterprise applications.

! """# $

#%

" $& $

'

% ( )** )# %

Figure 2shows this interaction in more detail.

Figure 2. A Java SE Application Using MVC
As this article mentioned earlier, the model does not carry a reference to the view but instead uses an event-notification model to notify interested parties
of a change. One of the consequences of this powerful design is that the many views can have the same underlying model. When a change in the data
model...