Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

HMVC: The layered pattern for developing strong client tiers

This hierarchical model eases the development of a Java-based client tier

By Jason Cai, Ranjit Kapila and Gaurav Pal, JavaWorld.com, 07/21/00

Page 2 of 5

Layered MVC -- HMVC

The HMVC pattern decomposes the client tier into a hierarchy of parent-child MVC layers. The repetitive application of this pattern allows for a structured client-tier architecture, as shown in Figure 1.

Figure 1. MVC layers

The layered MVC approach assembles a fairly complex client tier. Some of the key benefits of using HMVC reveal the benefits of object orientation. An optimally layered architecture:

• Reduces dependencies between disparate parts of the program
• Encourages reuse of code, components, and modules
• Increases extensibility while easing maintainability

Use HMVC to design a client-tier architecture

Though you may find the task daunting, you can effectively manage the development of a presentation layer for an application by incorporating smart development into your strategy -- that is, by using a robust and scalable pattern that can reduce some of the risk and provide a ready-made design foundation on which to build.

There are three key aspects of client-tier development:

• GUI layout code: Widget layout and screen look and feel
• GUI feature code: Validations and user-event capture
• Application logic code: App flows, navigation, and server interaction

The HMVC design pattern encourages the decomposition of the client tier into developed, distinct layers for implementing GUI and application services. A pattern-based architecture results in standardization; the HMVC pattern standardizes the presentation (user-service) layer of Web applications. Standardization in the presentation layer helps contribute to:

• UI consistency: The framework divides a visual entity (view) into panes with specific, consistent responsibilities and functionalities.
• Standardized interaction: The interaction between the various subcomponents within the presentation layer is clearly defined, providing customizable base classes.
• Maintainable code: Using a pattern results in maintainable code that provides a flexible and extensible code base for developing applications.
• Application flow support: The framework structures the presentation service into distinct layers and provides for inter- and intralayer communication. Such a structure offers a strong, orderly way to implement application logic and flow.

Design principles

The HMVC pattern provides clear delineation of responsibility among the different components and layers. Standard design patterns (Abstract Factories, Composite, Chain of Responsibility, Facade, etc.) can be used to provide a stable design.

Figure 2. HMVC layers and components

Figure 2 illustrates some layers and key components of the HMVC pattern. The horizontal layers specify the hierarchy within the application; the vertical slices refer to the components of the MVC triad. Within a layer, the controller has the overall responsibility of managing the model and view components. For example, the GUIFrame Controller controls the GUIFrame Model and the GUIFrame (the view). The dashed lines between model, controller, and view within a layer signifies clearly defined interfaces for communication. This interaction is achieved through AppEvents. For intralayer communication, a parent-child controller hierarchy exists, and all intralayer communication can only be routed through this path. Controllers interact by means of AppEvents.

View

A user interacts with the view, the visible portion of the application. HMVC abstracts views at different levels to provide a clean method for designing the GUI. At the highest level is a GUIContainer, with its associated controller. The container essentially holds potentially multiple views, called GUIFrame(s); each GUIFrame is a visual entity with which a user interacts. The framework defines a GUIFrame as composed of multiple subparts -- that is, a Menu GUIPane, a Navigation GUIPane, Status GUIPane, and a central Content GUIPane (see Figure 3). In most common Web applications, developers usually expect multiple GUIFrames to be unlikely; primarily, it is the Content GUIPane that needs to change. The Content GUIPane area is considered to be the most important part of the GUIFrame; that's where most of the user interaction occurs. The framework assumes that the efficient control of multiple Content GUIPanes will suffice to deliver a very large part of the user experience.

Figure 3. GUI components

Figure 3 illustrates a typical GUI frontend. It breaks into several parts (i.e., GUIPanes). We can apply the MVC triad to each of the composing panes and establish a hierarchy, with the GUIFrame being composed of the Menu, Status, Nav, and Content GUIPanes. Depending on the complexity of the code within each component, we may or may not assign an independent controller and model to a GUIPane. For example, because of its simplicity and lack of any real need for sophisticated control, it is not necessary for the Status GUIPane to have its own controller; we may choose to have the GUIFrame controller run the Status GUIPane instead. However, as the Content GUIPane is an important activity area, we might assign it a separate controller and model. Based on the MVC triad, a GUIFrame has its associated controller and data-holder model, as does the Content GUIPane. The GUIFrame layer has the GUIContainer as its parent triad. The GUIContainer is an invisible part of the architecture; it can potentially hold multiple GUIFrames.

A crucial aspect of the design is the isolation of Swing-specific code -- i.e., the Swing components and their listeners (refer back to Figure 2) -- within the lowest rung of the hierarchy. As an illustration, Swing widgets primarily compose the Content GUIPane. This is not a design limitation; a Nav GUIPane could also have a Swing component like, for example, a JTree. Therefore, the Content GUIPane is also responsible for catering to Swing events like ActionEvents. Similarly, an ActionEvent generated by clicking a JMenuItem within the Menu GUIPane is heard by the Menu GUIPane itself. Thus, a GUIPane acts as a listener for Swing events. The affected GUIPane can subsequently request further service from its controller by using application-level events. This allows for the localization of Swing-specific code.

Controller

The controller uses the model to coordinate the effects of user events on the view with the model; it also caters to logic flow. HMVC defines layers within the GUI and provides for distributed control of events through a parent-child hierarchy of controllers. Within a layer, the controller is the supreme commander, orchestrating the application flows and user-event responses. The Chain of Responsibility design pattern implements the controllers, wherein they pass on events that they can't cater to.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.