Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 5
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:
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:
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:
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
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.
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.