What is the Model-View-Controller Architecture

With the advent of JDK 1.1 a new event model was introduced into Java. This
event model is much cleaner than the previous approach and can result in
simpler, clearer and more maintainable code. The introduction of this event
model, along with existing Java facilities, allows the construction of modular
user interfaces. In particular it allows the separation of the display of
information, from the control or the user input to that display, as well as from
the application. This separation is not a new idea and allows the construction
of GUI applications that mirror the Model-View-Controller architecture. The
intention of the MVC architecture is the separation of the user display, from
the control of user input, from the underlying information model as illustrated

There are a number of reasons why this is useful:

· Reusability of application and / or user interface components,
· Ability to develop the application and user interface separately,
· Ability to inherit from different parts of the class hierarchy.
Ability to define control style classes which provide common features
separately from how these features may be displayed.
Figure 1: The Model-View-Controller architecture

This means that different interfaces can be used with the same application,
without the application knowing about it. It also means that any part of the
system can be changed without affecting the operation of the other. For
example, the way that the graphical interface (the look) displays the
information could be changed without modifying the actual application or how
input is handled (the feel). Indeed the application need not know what type of
interface is currently connected to it at all.

MVC defines the separation of these three types of objects:

Model objects hold data and define the logic for manipulating that data. For example, a Student object in the Basic sample application is a model object. It holds data describing facts about the object like the first and last name of the student and has methods that can access and change this data (getters & setters). Model objects are not directly displayed. They often are reusable, distributed, persistent and portable to a variety of platforms.
View objects represent something visible in the user interface, for example a panel or button. In order to display the data from the model objects you might want to create your own custom objects, like a graph for example.
The Controller object acts as a Mediator between the Model and View objects. A Controller object communicates data back and forth between the Model objects and the View objects. For example a controller could mediate the first name of a student from a model object to a visible text field in the User Interface. A controller also performs all application specific tasks, such as processing user input or loading configuration data. There is usually one controller per application or window, in many applications the Controller is tightly coupled to the view. The Basic sample application shows this - every GUI class implements its own ActionListeners. Since controllers are application specific they usually do not find any reuse in other applications.

2. What Java facilities support the MVC

Java provides two facilities that together can allow the separation of the
application, interface and control elements. These are:
· The observer / observable model. This allows application programs and
user interfaces to be loosely coupled.
· The delegation event model. This provides listeners which act as
controllers handling various events that may occur.
The use of the observer / observable mechanism is very powerful and has
been used to create MVC style clients. However in this article we will focus on
the use of the delegation event model. Why is? Essentially because more
developers are familiar with the delegation event model and it can be used as
successfully as the observer-Observable model to allow models to notify their
views of the need to perform a redisplay style operation.

2.1 The Delegation Event Model

The Java delegation event model introduced the concept of listeners
[Sevareid 1997]. Listeners are effectively objects that “listen” for a particular
event to occur. When it does they react to it. For example, the event
associated with the button might be that it has been “pressed”. The listener
would then be notified that the button had been pressed and would decide
Display/
View
Control of
User Input
Information
Model

what action to take. This approach involves delegation because the
responsibility for handling an event, generated by one object, may be another
objects’.
The delegation model changed the way in which users created GUIs back in
JDK 1.1. Using this model they defined the graphic objects to be displayed,
added them to the display and associated them with a listener object. The
listener object then handled the events that were generated for that object.
For example, if we wish to create a button which will be displayed on an
interface and allow the user to exit without using the border frame buttons,
then we would need to create a button and a listener for the action on the
button:
exitButtonController = new ExitButtonController();
exitButton = new Button(" Exit ");
exitButton.addActionListener(exitButtonController);
This code creates a new user defined listener object, ExitButtonController,
then creates a new button (with a label exit). It then adds the
exitButtonController as the action listener for the button. That is, it is the object
which will listen for action events (such as the button being pressed). The
ExitButtonController class (presented below) provides a single instance
method actionPerformed() which will initiate the System.exit(0) method.
Figure 2: The class and object diagram using the delegation event model
The resulting class and instance structures are illustrated in Figure 2. As you
can see from this diagram, the separation of interface and control is
conceptually very clean.
The ExitButtonController class definition is presented below. There is of
course no reason why you should call such classes controller, you could
equally have called it an ExitButtonEventListener. However, the Listeners are
the interface definitions. By choosing a different type of name, we make it
clear we are talking about the classes intended to provide the execution
control:
class ExitButtonController
implements ActionListener {
public void actionPerformed(ActionEvent event) {
Frame ActionListener
WindowListener
SimpleGUI ExitButtonController
anExitButtonController aSimpleGUI 2. Event notification
1. User
interaction
3. Method
invocation

www.PlanetJava.co.uk www.JayDeeTechnology.co.uk
Page 4
System.exit(0);
}
}

3. The MVC in Java

To provide a framework for the MVC within Java we can adopt a number of
techniques, however the approach adopted here is illustrated by Figure 3. This
diagram shows three interfaces (namely Controller, View and Model) that acts
as markers for the core concepts or entities in the MVC framework. Note that
the Controller and View interfaces define accessor methods for obtaining the
model and either the view or controller respectively.
Figure 3: The interfaces defining the MVC entities
In Figure 3 the interface of most note is the Model interface. This interface
contains just one method: the notifyChanged(ModelEvent event) method. This
method will be used by all implementations of models to notify any interested
objects of changes in the state of the Model. At this point all we know is that
such a method will be provided and that the parameter to this method is
ModelEvent.
This leads on nicely to Figure 4. This is the heart of the notification
mechanism used within this implementation of the MVC. When a model
wishes to notify interested objects of a change in its state. I must create a
ModelEvent object (just as JButton creates an ActionEvent to notify a handler
that a user has clicked on it). In this cases the ModelEvent object has been
made a subclass of ActionEvent however it does not need to subclass this
class – it could subclass any Event object as identified by a designer. The
ModelEvent class adds an additional property to those inherited, this property
allows a ModelEvent to hold an amount value (this is really tying too closely to
the calculator application but keeps things simpler later on).
As we are defining our own event class, we also need to define a listener
interface for objects that wish to be notified of ModelEvent. The ModelListener