Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click Here!
Click Here!
ITKnowledge
Find:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Chapter 2
MVC Architecture

In This Chapter
•  The MVC Architecture
•  Combined View and Control in JFC
•  Factory Design Pattern
•  Singleton Pattern

The design of the JFC is built upon a variant of the Model View Controller (MVC) architecture. This is not a new architecture for software applications, but it is new to the Java graphical user interface toolkit. MVC is a well-understood architecture that has been used in other programming languages for years. The JFC makes extensive use of a couple of design patterns. Understanding the architecture and these patterns will enhance your ability to build robust JFC applications.

The JFC can be used like a typical graphical user interface toolkit: create and arrange a display’s buttons, lists, and so on. If the user interacts with the display, the data is queried from the view and stored elsewhere in the application. Similarly, if the application’s data changes, the program queries the data and updates the view components. In this scenario, the view contains its own copy of the data it displays. The application is responsible for keeping the view’s data in sync with its internal data representation.

The JFC can be used in this dumb toolkit mode, but by doing so you ignore a much more powerful underlying technology called the Model View Controller (MVC) architecture. In MVC, the application data is contained in the model, one or more views are used to present the data to the user, and controls are used to interact with the data in the model.

The remainder of this chapter describes the MVC architecture, as well as a few other design patterns common in the JFC.

The MVC Architecture

The Model View Controller architecture consists of three types of classes. The model consists of the application data classes. The view consists of the application presentation. The controller classes define how user interaction is handled in the application. The MVC architecture decouples these functional components, allowing for easier reuse of code than in a traditional user interface toolkit.

Some communication mechanisms must be provided with the decoupled functional entities in the MVC architecture. In the JFC, a subscribe-and-publish paradigm is employed. Under this paradigm, objects express interest in a data source by subscribing. When the data source changes state, a notification is published to the subscribed object. Multiple objects can subscribe to the same data source at the same time. Similarly, an object can subscribe to multiple data sources. An object unsubscribes from a data source when it is no longer interested in it. After unsubscribing, the data source will not send additional events to the subscriber. The controller objects are used to mutate the data sources. The mutation is typically accomplished by calling a method on the data model.

The MVC example shown in Figure 2.1 shows that the views have subscribed to the model data source. A source of input causes the first controller object to send a message that changes the data contained in the model. After the model has changed its state, it publishes a change message to each of the views that have previously subscribed with the model. In this example, the entities that subscribe to the model are shown as views.


Figure 2.1  MVC communication example.

However, any type of object can subscribe to receive data change messages. For example an object that logs changes to a file could subscribe to the data model. It is important to understand that the order in which subscribers are notified is undefined. This gives models the flexibility to serve subscribers in any way convenient for that model. It also prohibits designing views that require notifications in a specified order from a single model. If notification order is required, subscribers must daisy chain themselves and forward the notification in the proper order. This situation is depicted in Figure 2.2. Daisy chaining subscribers complicates each subscriber. It must be capable of accepting subscription requests and publishing messages when they are received.


Figure 2.2  Daisy-chained subscribers.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.