Model-View-Controller - Part 1

In this advanced tutorial, we discuss how to put into practise the knowledge you have gained about Graphical User Interface development. Often, people have problems trying to determine where to place a GUI within a project, or the system logic within a GUI class.

One of the best ways of working with a GUI is to use the "Model-View-Controller" code structure. This structure has been mentioned before in JTextField Part 3 (Restricting your JTextField) in a brief way, but here we want to go deeper into the theory of MVC, and show you a proper example.

As you may guess, the MVC structure is split into three separate sections.

• Model - Contains the data for your program, along with the logic, methods and functions to manipulate this data.
• View - Means of displaying the data within the model. Probably a GUI, but could be audio, printouts or any kind of thing.
• Controller - Maps the users actions in the view to model updates.

As you can see, the work we have done for GUIs has fitted very nicely within the 'View', creating a GUI that contains no application data.

Interaction between Components

Now to understand how each part interacts with one another. The controller is, usually, the component in control. The ActionListeners are stored within the Controller, along with any other input devices (such as a command from the network, a external device like a joystick or mouse etc). When something occurs, the controller updates the view and the model with the changes.

There are two methods for this. The view can get information from the model by asking the controller so as to display the correct information (The pull method), or can register itself with the controller to receive information when the model changes (The push method). However, the view may never change the model directly and the model can never change the view directly, any changes must go through the controller.

With most things of this nature, you may find yourself asking.... why?

By separating the data, controller and GUI from one another, changes that are to be made to the system generally only affect one section. In this example, we will replace the entire GUI without needing to make changes to the Controller or Model! The underlying model can be upgraded and the existing segments can be tested without changing the GUI or the Controller! And the actions that occur when a user interacts with the application can be modified in the Controller without affecting the model or view.

Another great reason for the MVC is the breakdown of work. Once the relationships between each section have been decided, The View, Controller and Model can be written concurrently. Set one person to write the View, and he/she needs little interaction with the person writing the Controller...particularly useful for Group Projects!

To demonstrate the MVC structure, we will create a basic Calculator by going through the steps of Model, View and Controller.