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