HMVC: The Layered Pattern for Developing Strong Client Tiers, Part 2 This hierarchical model eases the development of a Java-ba

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


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


* 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


* 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.

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 signify

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



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.

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,

the Menu GUIPane itself hears an ActionEvent generated by clicking a

JMenuItem within the Menu GUIPane. 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.

Next Week: Part 3

ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon