文章目录

• Overview
• Origins and Motivation
• Structure
• Components
• Collaborations
• MVC Misconceptions
• Pattern Variations and Derivatives
• Origins and Motivation
• Structure
• Components
• Collaborations
• Overview
• Origins and Motivation
• Components
• Collaborations
• Dolphin Smalltalk MVP vs. Smalltalk-80 MVC
• Overview
• Structure
• Components
• Collaborations
• Overview
• Structure
• Components
• Collaborations
• Overview
• Structure
• Components
• Collaborations
• Structure
• Components
• Collaborations
• Overview
• Origins and Motivation
• Structure
• Collaborations
• Pattern Variations and Derivatives

[转]Interactive Application Architecture Patterns                                     

          Created by: Derek Greer

          Excerpted by: Zhou Yinhui

          Original : http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

 

This article presents an introduction, overview, and comparison of three similar interactive application architecture patterns: the Model-View-Controller, Model-View-Presenter, and Presentation-Abstraction-Control pattern.

 

Introduction

The MVC, MVP, and PAC patterns are each intended to address the needs of interactive applications by separating the concerns assigned to different components within their respective architectures. While similar, each of these patterns differs slightly in their motivations and applicability to various design goals. This article discusses each pattern along with its history and design motivations to encourage the correct understanding and application of these patterns.

In discussing architecture patterns in general, it is helpful to understand that patterns in this class are often motivated by design considerations which were formed within the context of specific development environments. As such, platform specific motivations and the pattern’s implementation details often become part of the formal description of the pattern.

For instance, the Model-View-Controller pattern had the primary design motivation of separating presentation from domain concerns. The division between the input and output of the application, which resulted in the concept of the Controller component, was really a byproduct of the complexities required in dealing with device input and output. Today’s development environments have come a long way in shielding developers from such complexities, making divisions between device input and output at the application level unnecessary. In such environments, the application of the Model-View-Controller pattern may result in an approach which adheres to the intent of the pattern while not following its original form, or adheres to its original form without following its original intent. For example, the original goals of the Model-View-Controller pattern can be accomplished today within many development environments by merely separating an application’s Forms and associated Controls from a Domain Model or other domain specific implementation strategy. The inclusion of a Controller for intercepting user input is unnecessary in platforms which natively provide this functionality. When attempting to follow the original form of the Model-View-Controller pattern within such development environments, the resulting architecture may fall somewhere between a strict implementation of MVC which goes against the grain of the hosting environment and an implementation which assigns different responsibilities to the original components.

From this observation it can be deduced that the Model-View-Controller pattern hasn’t adequately been distilled into pattern language. That is to say, the components prescribed by the MVC pattern are not agnostic of the assumed development environment, and most descriptions do not make this explicit. This often results in the misapplication of the pattern.

Another suggestion when studying and considering the use of interactive design patterns is to take the whole subject with a grain of salt. Many of the base patterns, such as those presented in the seminal work Design Patterns – Elements of Reusable Object-Oriented Software by Gamma, etc. al. are well distilled patterns which describe solutions to common problems in a implementation-agnostic way. Because of the nature of these patterns, we don’t generally find scores of competing constructs purporting to address the same issue. However, when entering the realm of compound patterns such as interactive application patterns, models, styles, etc., the study of such constructs can feel a bit like watching a documentary of the history of airplanes. Is that a Controller I see in that last image?

It’s best to think of architecture patterns as being as much in the realm of art as science. Interactive architecture patterns aren’t the computer science equivalent of Newton’s Law of Gravity. They merely represent our ever evolving attempt to achieve the best model for the needs of the day.

Finally, when considering the use of these various patterns, remember that you should be considering them for their applicability to your problem, not so you can proclaim: “I use the such-and-such pattern” with thumbs tucked securely under the straps of your overalls. The use of patterns should be the result of having started with a problem for which an existing pattern was known or found to be applicable, not the result of starting with a pattern for which a problem was sought out or invented to be applicable. With that said, let’s proceed with the discussion.

The Model–View-Controller Pattern

Overview

The Model-View-Controller pattern is a methodology for separating the concerns of an application’s data, presentation, and user input into specialized components.

Origins and Motivation

The MVC pattern was originally conceived in 1978-79 by Trygve Reenskaug and had the primary goal of providing an interface for users to manipulate multiple views of data as if working with real world entities. The pattern was first referred to as the Thing-Model-View-Editor before Reenskaug and his colleges settled on the name Model-View-Controller (1). A modified version of Dr. Reenskaug’s design was later implemented as part of the Xerox PARC Smalltalk-80 class library. A description of this implementation can be found in the work: Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC).

Structure

The following diagram depicts the structure of the Model-View-Controller pattern:

 

 

Note: While some descriptions of the MVC pattern show an indirect association from the View to the Controller, the original implementation of MVC in Smalltalk-80 coupled View to Controller, and vice-versa (2).

 

Components

The Model refers to the data and business functionality of the application. This is often represented by a Domain Model where objects seek to model real world entities by representing their properties and behavior.

The View is the visual representation of the Model and is comprised of the screens and widgets used within an application.

The Controller is a component which responds to user input such as data entry and commands issued from a keyboard or mouse. Its responsibility is to act as a bridge between the human and the application, allowing the user to interact with the screen and data.

Collaborations

Within the MVC pattern, a Model-View-Controller triad exists for each object intended to be manipulated by a user.

The Model represents the state, structure, and behavior of the data being viewed and manipulated by the user. The Model contains no direct link to the View or Controller, and may be modified by the View, Controller, or other objects with the system. When notification to the View and Controller are necessary, the Model uses the Observer Pattern to send a message informing its dependants that the data has changed.

The View and Controller components work together to allow the user to view and interact with the Model. Each View is associated with a single Controller, and each Controller is associated with a single View. Both the View and Controller components maintain a direct link to the Model.

Note: Within the Smalltalk-80 implementation, both the View and Controller maintained a direct link to one another, though the link from the View to the Controller was largely a byproduct of its implementation rather than an inherent part of the MVC pattern. The link was not maintained to delegate user input intercepted by the View to the Controller as is the case with the Dolphin Smalltalk Model-View-Presenter pattern, but was rather used by the View to initialize the controller with an instance of itself, and by a top level Controller to locate the active Controller within a View hierarchy.

The View’s responsibility can be seen as primarily dealing with output while the Controller’s responsibility can be seen as primarily dealing with input. It is the shared responsibility of both the View and the Controller to interact with the Model. The Controller interacts with the Model as the result of responding to user input, while the View interacts with the Model as the result of updates to itself. Both may access and modify data within the Model as appropriate.

As data is entered by the user, the Controller intercepts the user’s input and responds appropriately. Some user actions will result in interaction with the Model such as changing data or invoking methods, while other user actions may result in visual changes to the View such as the collapsing of menus, the highlighting of scrollbars, etc.

MVC Misconceptions

One common misconception about the relationship between the MVC components is that the purpose of the Controller is to separate the View from the Model. While the MVC pattern does decouple the application’s domain layer from its presentation layer, this is achieved through the Observer Pattern, not through the Controller. The Controller’s job is to mediate between the human and the application, not between the View and the Model.

Pattern Variations and Derivatives

The classic Model-View-Controller pattern is largely no longer used today in its original design, though it has given rise to a number of variations adapted to newer development platforms such as Microsoft Windows and Web development. Two of these variations, the Model-View-Presenter and Presentation-Abstraction-Control patterns will be discussed in the remainder of this article.

The Model-View-Presenter Pattern

The Model-View-Presenter pattern is a variation on the Model-View-Controller pattern, and similarly separates the concerns of an application’s data, presentation, and user input into specialized components.

The definition and distinctive characteristics of this pattern are not easily summarized due to the fact that there are several patterns commonly accepted under the name “Model-View-Presenter” which do not share the same distinctive qualities over their predecessor, the Model-View-Controller pattern. For this reason, this article will discuss the original Model-View-Presenter pattern along with some of its variations and derivatives.

The Taligent Model-View-Presenter Pattern

Overview

The Taligent Model-View-Presenter pattern separates the application concerns of data, data specification, data manipulation, application coordination, user interaction, and presentation into specialized components.

Origins and Motivation

The MVP pattern was based on the Taligent programming model, which itself was influenced by the original Smalltalk-80 MVC pattern. The pattern was first formally described by Mike Potel in 1996 while working for Taligent, Inc.. Taligent was started by Apple Computer, Inc. as a joint venture with IBM (and later joined by Hewlett Packard) before becoming the wholly owned subsidiary of IBM in late 1995. Many of the elements of the original MVP pattern began taking form at Apple under the management of Larry Tesler, who formerly worked at Xerox PARC where he was one of the contributors of the design and implementation of Smalltalk.

While the main elements of the pattern were already being utilized at Taligent between 1992 and 1994, it wasn’t until after Taligent, Inc. was purchased by IBM in 1995 that Mike Potel first suggested the name “Model-View-Presenter” to describe the architecture found within the Taligent programming model. Dr. Potel credits Arn Schaeffer, Dave Anderson, and David Goldsmith as leading contributors to the Taligent programming model from which the MVP pattern was derived (3).

Structure

The following diagram depicts the structure of the Taligent Model-View-Presenter pattern:

 

 

Components

The Model refers to the data and business functionality of the application.

Selections are components which specify what portion of the data within the Model is to be operated upon. Examples would be selections which define rows, columns, or individual elements which meet specific criteria.

Commands are components which define the operations which can be performed on the data. Examples might be deleting, printing, or saving data within the Model.

The View is the visual representation of the Model and is comprised of the screens and widgets used within an application.

Interactors are components which address how user events are mapped onto operations performed on the Model, such as mouse movements, keyboard input, and the selection of checkboxes or menu items.

The Presenter is a component which orchestrates the overall interaction of the other components within the application. Its roles include the creation of the appropriate Models, Selections, Commands, Views, and Interactors, and directing the workflow within the application.

Collaborations

The most notable collaborative differences between the Taligent Model-View-Presenter pattern and the Model-View-Controller pattern are found within the Presenters and Interactors.

The Presenter acts as an overall manager for a particular subsystem within an application. It maintains the lifecycle and relationships between the Views, Interactors, Commands, Selections, and Model. The responsibility for intercepting user events is governed by Interactors; therefore Presenters are not needed for each widget on a given View as were Smalltalk-80 Controllers. There is generally a single Presenter per View, though in some cases a Presenter may manage multiple logically related Views.

Interactors are somewhat analogous to Smalltalk-80 Controllers. They are the components which respond to user events and in turn call the appropriate Commands and Selections of the Model.

The Dolphin Smalltalk Model-View-Presenter Pattern

Overview

The Dolphin Smalltalk Model-View-Presenter pattern separates an application’s concerns of data, presentation, and presentation logic into the specialized components of Model, View, and Presenter. The Dolphin Smalltalk team simplified the Taligent MVP pattern by eliminating Interactors, Commands, and Selections from the pattern’s formal description. This in turn simplified the role of the Presenter, changing it from a subsystem controller to a component which mediated updates to the Model on behalf of the View.

Origins and Motivation

The Dolphin Smalltalk Model-View-Presenter pattern was adapted from the Taligent Model-View-Presenter pattern to address flexibility issues the Dolphin development team was having in its approach to view/domain separation. One of the team’s early considerations included a variation on the MVC pattern used by ParcPlace Systems’ VisualWorks. While the Dolphin team considered the VisualWorks MVC design initially, they later became disenchanted with its prescribed Application Model whose complexity at times tempted developers to allow the model to access the view directly. They also found that the MVC concept of a Controller, whose primary purpose was to respond to user events, didn’t mesh well with more current development platforms whose native widgets handled user events directly. After encountering the Taligent MVP pattern, the Dolphin team concluded it was more applicable for achieving their design goals. While they saw benefits in the Taligent MVP pattern, they mistakenly believed that Taligent derived their pattern from the VisualWorks’ MVC implementation and had eliminated the use of an Application Model by moving presentation logic concerns from the Model to the Presenter. They described this as “Twisting the Triad”, though this does not accurately portray the differences between the Taligent MVP pattern and the original Smalltalk-80 MVC pattern. Due to this misunderstanding, they viewed the Presenter component as being a replacement of the Application Model within VisualWorks’ MVC rather than an evolution of the Controller component within the Smalltalk-80 MVC. The resulting pattern implemented by the Dolphin Smalltalk team was void of most of the components which gave the original MVP its distinctiveness from MVC, though it introduced distinctive qualities of its own.

 
Structure

The following diagram depicts the structure of the Dolphin Smalltalk Model-View-Presenter pattern:

 

 

Components

The Model refers to the data and business functionality of the application.

The View is the visual representation of the Model and is comprised of the screens and widgets used within an application.

The Presenter is a component which contains the presentation logic which interacts with the Model.

Collaborations

Within the Dolphin MVP pattern, Views intercept the initial user events generated by the operating system. This choice was primarily the result of development on the Microsoft Windows operating system whose native widgets already handled most controller functionality. In a few cases the View responded to user events by updating the Model directly, but in most cases user events were delegated to the Presenter. Implied by the Dolphin Smalltalk description is that Views only delegated events when updates to the Model were required, thus leaving all other presentation logic within the View.

As with the Taligent MVP pattern, there is usually a single Presenter which handles updates to the Model for a specific View.

As with the Model-View-Controller pattern, the View is notified of any changes to the Model using the Observer Pattern and responds by updating the relevant portions of the screen.

Dolphin Smalltalk MVP vs. Smalltalk-80 MVC

On the surface, the differences between the Dolphin Smalltalk MVP pattern and the Smalltalk-80 MVC pattern are difficult to discern. Both of the patterns contain a triad. Both of the patterns contain a Model and View which are virtually identical in function. Both the Smalltalk-80 Controller and the Dolphin Smalltalk Presenter are involved in updating the Model. Both of the patterns use the Observer Pattern to update the View when changes occur to the Model. With all these similarities, it is clear why so much confusion surrounds understanding how the Model-View-Presenter pattern sets itself apart from the Model-View-Controller pattern. The key is in understanding the primary functions which Presenters and Controllers play within their respective triads.

Within the original Model-View-Controller pattern, the primary purpose of the Controller was to intercept user input. The Controller’s role of updating the Model was largely a byproduct of this function rather than an inherent part of its purpose.

Conversely, within the Dolphin Smalltalk Model-View-Presenter pattern, the primary purpose of the Presenter was to update the Model. The Presenter’s role of intercepting events delegated by the View was largely a byproduct of this function rather than an inherent part of its purpose.

Part of the original idea leading to the development of the MVC pattern was a separation between the representation of a user’s mental idea of the data (i.e. the Model), and the logic which allowed the user to interact with that representation (i.e. the Editor). This was considered Model/Editor separation (4). Because the tasks involved in displaying data on the screen were technically very different from the tasks involved in interpreting the user’s input from devices such as the keyboard and the mouse, the combination of these tasks into a single object resulted in unnecessary complexity. Therefore, the concerns of input and output were separated into Views and Controllers. Because Controllers were assigned the input responsibility of the Editor, it naturally followed that they took on the responsibility of updating the Model when input was received from the user.

Within the Dolphin Smalltalk MVP pattern, the role of intercepting the user’s input was moved to the View. This effectively eliminated the original need for Controllers or Interactors altogether. While the original idea of the Presenter was seen by the Taligent team as a Controller elevated to an application level, the Dolphin team mistakenly considered it a replacement of the VisualWorks’ Application Model and maintained the Presenter as a mediating component within the triad.

So then, while the Dolphin Smalltalk MVP and the Smalltalk-80 MVC patterns may appear similar on the surface, Presenters and Controllers differ in the purposes they were conceived to address.

The Fowler Patterns

During his research and preparation of material on presentation layer patterns in 2006 for an upcoming book, Martin Fowler decided that the treatment given to the design intensions behind today’s use of the Model-View-Presenter pattern be divided under the names Supervising Controller and Passive View. This distinction was made around the level of responsibility the Presenter/Controller component of the pattern takes on for presentation layer logic.

The Supervising Controller and Passive View patterns are well distilled constructs which deal with the concerns of presentation logic apart from any specific domain logic strategy. This distilment renders patterns which describe solutions not specific to the Model-View-Presenter pattern, and are an excellent example of how patterns come about. While discussed here within the context of the Model-View-Presenter pattern, these patterns are best understood as facilitating patterns (as with the Observer Pattern) rather than variations of the Model-View-Presenter pattern.

The Supervising Controller Pattern

Overview

The Supervising Controller pattern separates an application’s concerns of presentation and presentation logic into the specialized components of View and Controller, with the View assigned the responsibility of simple presentation logic and the Controller assigned the responsibilities of responding to user input and handling complex presentation logic.

Structure

The following diagram depicts the structure of the Supervising Controller pattern:

Note: The model is here depicted in gray to denote its peripheral role to the pattern description.

 

Components

The View is the visual components used within an application such as screens and widgets.

The Controller is a component which processes user events and the complex presentation logic within an application.

Collaborations

Within the Supervising Controller pattern, Views delegate user events to the Controller which in turn interacts with the business domain of the application.

For simple presentation logic, the View uses data binding techniques and the Observer Pattern to update itself when changes occur within the application.

Complex presentation logic, particularly any logic one desires to unit test, is delegated to the Presenter.

 

The Passive View Pattern

Overview

The Passive View pattern separates an application’s concerns of presentation and presentation logic into the specialized components of View and Controller, with the Controller taking on the responsibility for responding to user events and presentation logic.

Structure

The following diagram depicts the structure of the Passive View pattern:

 

Note: The model is here depicted in gray to denote its peripheral role to the pattern description.

Components

The View is the visual components used within an application such screens and widgets.

The Controller is a component which processes user events and the presentation logic within an application.

Collaborations

Within the Passive View pattern, Views delegate user events to the Controller which in turn interacts with the business domain of the application and/or updates the View. The View maintains no link to the domain layer and relies solely on the Controller for all presentation related logic.

Controllers within this pattern take on a mediating role between the Views and domain logic strategy used. This formalizes a role often erroneously ascribed to Controllers within the Model-View-Controller pattern.

The Passive View Pattern

Beginning with the Composite UI Application Block, and more formally in the Smart Client Software Factory and Web Client Software Factory released by the Microsoft Pattern & Practices teams in 2006, Microsoft began incorporating the MVP pattern into its guidance automation, documentation, examples, and labs. In addition to the Model, View, and Presenter components, the Web Client Software Factory also encourages the user of an Application Controller (5) for decoupling page flow logic from presentation specific logic.

While Microsoft’s implementation of the Model-View-Presenter pattern doesn’t differ significantly from the Dolphin Model-View-Presenter description, its implementation and incorporation into these popular frameworks are worthy of note due to their influence on the .Net community’s perspective on this pattern.

The Microsoft Model-View-Presenter Pattern

Overview

The Microsoft Model-View-Presenter pattern separates an application’s concerns of data, presentation, and presentation logic into the specialized components of Model, View, and Presenter.

Structure

The following diagram depicts the structure of the Microsoft Model-View-Presenter pattern implementation:

 

Components

The Model refers to the data and business functionality of the application.

The View is the visual representation of the Model and is comprised of the Forms and Controls used within an application.

The Presenter is a component which contains the presentation logic which interacts with the Model and optionally updates the View.

Collaborations

Within the Smart Client Software Factory, each View is defined with a corresponding View interface and Presenter. Each View creates a private instance of its Presenter upon initialization, and each Presenter is defined with a reference to the View interface type which is set by the View after creation. As user events are intercepted by the View, the code-behind invokes methods on the Presenter which in turn interact with the Model. In addition to methods which mediate access to the Model, the Presenter is typically created with methods to be invoked when the View is ready to be displayed and when the View is ready to be closed. Presenter methods are typically named abstractly to denote a particular action to be taken as opposed to having any direct correspondence to event names contained within the View.

The Model is often represented by a suite of business layer components within the application rather than a traditional Domain Model. The business layer typically consists of Business Entities, Business Workflows, and Business Components as described in the book Application Architecture for .Net: Designing Applications and Services. The Presenter also often interacts with the domain layer through a service layer allowing further abstraction techniques to be used within the application.

While the Smart Client Software Factory demonstrates the Model-View-Presenter pattern in its example applications, the most interesting and influential aspect of its use are found in the provisioning of code generation recipes that work with Microsoft’s Guidance Automation Extensions for Visual Studio.

When developing with the Smart Client Software Factory, the user interacts with context sensitive menus which provide code-generation recipes for implementing various aspects of an application. One of the recipes provided is the ability to create a new View with an associated Presenter. Upon selecting the “Add View (with presenter) …” menu item on the Smart Client Factory context menu, the user is presented with a dialog screen containing a field for the desired View name along with options for creating a containing folder and displaying documentation after the recipe completes. The user is also presented with a list of the names of the View, View interface, and Presenter to be created in addition to the optional containing folder name. Once the recipe is executed, the classes are generated for the user.

The generated View class contains a private instance of the generated Presenter, code to initialize the Presenter’s reference to the View, code to dispose of the Presenter when the View class is disposed, and a call to the Presenter’s OnViewReady() method from the View’s OnLoad() method. The generated Presenter contains the methods OnViewReady() and OnCloseView(). It also extends a previously generated generic base Presenter type which defines properties and methods common to all presenters within the Smart Client Software Factory.

 

The Microsoft Model-View-Presenter with Application Controller Pattern

 
Overview

The Microsoft Model-View-Presenter with Application Controller pattern separates an application’s concerns of data, presentation, presentation logic, and page flow concerns into the specialized components of Model, View, Presenter, and Controller.

Structure

The following diagram depicts the structure of the Microsoft Model-View-Presenter pattern coupled with the Application Controller pattern:

Components

The Model refers to the data and business functionality of the application.

The View is the visual representation of the Model and is comprised of the Forms and Controls used within an application.

The Presenter is a component which contains the presentation logic which interacts with the Application Controller.

The Controller is a component which contains the page flow logic and interacts with the Model on behalf of the Presenter.

Collaborations

Within the Web Client Software Factory, applications are broken down into separate modules of functionality, each containing their own Application Controller. Presenters maintain the responsibility of updating the View when the Model changes, but delegates both page flow and Model interaction concerns to the Application Controller.

As with the Smart Client Software Factory, the Web Client Software Factory also has a rich set of Guidance Automation recipes which allow for the creation of Views, Presenters, and Application Controllers. When used with an Application Controller, Presenters simply contain a private instance of the Controller and delegates all methods which are not limited to presentation only concerns.

The Presentation-Abstraction-Control Pattern

Overview

The Presentation-Abstraction-Control pattern is an architecture which separates the concerns of an application into a hierarchy of cooperating components, each of which are comprised of a Presentation, Abstraction, and Control. The PAC pattern seeks to decompose an application into a hierarchy of abstractions, and to achieve a consistent framework for constructing user interfaces at any level of abstraction within the application.

Origins and Motivation

The PAC pattern was conceived by Joëlle Coutaz in 1987. The goal of the pattern was to provide a model for developing interactive applications which bridges the gap between theoretical models for human/computer interaction and the practical concerns of building user interfaces. The original pattern description can be found in the publication: “PAC, and Object Oriented Model for Dialog Design”.

In her article, Coutaz sets forth that the PAC model more closely follows the cognitive organization of human knowledge. That is to say, the human mind doesn’t perceive the world in layers, but rather in an interconnected web of abstract ideas.

Structure

The following diagram depicts the structure of the Presentation-Abstraction-Control pattern:

 Components

The Presentation is the visual representation of a particular abstraction within the application. It is responsible for defining how the user interacts with the system.

The Abstraction is the business domain functionality within the application.

The Control is a component which maintains consistency between the abstractions within the system and their presentation to the user in addition to communicating with other Controls within the system.

Note: Later descriptions generally use the term “agent” to describe each Presentation-Abstraction-Control triad.

Collaborations

Conceptually, the Presentation-Abstraction-Control pattern approaches the organization of an application as a hierarchy of subsystems rather than layers of responsibility (e.g. Presentation Layer, Domain Layer, Resource Access Layer, etc.). Each system within the application may depend on zero or more subsystems to accomplish its function. Each subsystem presents a finer grained view of an aspect of the overall system. By organizing systems into a hierarchy of subsystems, each of which are composed of the same PAC components, any level of granularity of the system can be inspected while maintaining the same architectural model.

While interaction between the user and the application occurs through the Presentation components, interaction within the Presentation-Abstraction-Control pattern is accomplished exclusively through the Control element of each triad. The Control exists to bridge the gap between the presentation and the abstraction and maintains extensive knowledge about both components (6). Its responsibilities include updating the view, accessing the abstraction, maintaining state, thread management, flow control, and interaction with parent and child Controls.

There exists no direct link between the Presentation and Abstraction within a PAC object (7).

Pattern Variations and Derivatives

From 1989 through 1995, the Commission of the European Communities funded two Human Computer Interface research projects under the names Amodeus and Amodeus-2 (8). Amodeus was an acronym for “Assimilating Models of Designers, Users and Systems”. During Amodeus-2, a researcher named Laurence Nigay, working under the supervision of Joëlle Coutaz, created the PAC-Amodeus Model. PAC-Amodeus is a model which blends the software components advocated by the Arch Model and the multi-agent model prescribed by the Presentation-Abstraction-Control pattern (9). The Arch Model was proposed by Len Bass at a UIMS Tool Developers’ Workshop in 1991 as a way to accommodate rapidly changing UI requirements (10) and itself was a derivative of the Seeheim Model developed in 1985. In many ways the Arch Model was similar to the Taligent Model which was to follow only a few years later. It prescribed a central Dialog Controller which mediated the interaction between the presentation and domain layer components, and used explicit components to define the interaction between the controller, presentation, and domain components. While the Arch Model prescribed specific components to accomplish its goal of flexibility and reuse, the underlying principle at work was its adherence to a layered organization of the application. While PAC provided a highly organized and uniform pattern for decomposing the tasks performed by an application, its insistence on a homogeneous design led to tightly coupled components which were difficult to maintain and reuse. The benefits of the layered approach were appreciated in the Arch Model, but the prescribed Dialog Controller was seen as too vague and all encompassing. It was therefore decided to use the Arch Model as the foundational model, but organize the tasks accomplished by the Dialog Controller into a series of PAC agents whose Presentation and Abstraction components mapped into other layered components within the Arch Model.

Another derivative of PAC, by way of PAC-Amodeus, is PAC*. PAC* was developed by Gaelle Calvary, Laurence Nigay, and Joëlle Coutaz around 1997 (11). PAC* follows the PAC-Amodeus style of using the Arch Model as the base architecture with a dialog controller organized as PAC agents, but also incorporates concepts found within a model named Dewan’s Generic Architecture for addressing layer replication within multi-user applications.

Full discussions of the PAC-Amodeus and PAC* are beyond the scope of this article, but a good summary of the Seeheim, Arch, PAC, PAC-Amodeus, and PAC* models among others can be found in a technical report by W. Greg Phillips entitled: “Architectures for Synchronous Groupware”.

Another pattern worthy of note is the Hierarchical-Model-View-Controller pattern. While not a direct derivative of the PAC family of patterns, the HMVC pattern is often associated with PAC due to its similarities. The HMVC pattern was first described in an article which appeared in JavaWorld Magazine in July of 2000. Developed by Jason Cai, Ranjit Kapila and Gaurav Pal, the HMVC pattern is a prescription for organizing Model-View-Controller triads into a hierarchy for organizing the presentation layer of a rich client application such as Java Swing applications. While its organization of MVC triads into a hierarchy is similar to PAC, it differs in that Model and View components maintain the same observer relationship as within MVC, and more notably that it seeks only to address the presentation layer of an application rather than addressing the entire application architecture. While derived from the Model-View-Controller pattern, Controllers within the HMVC pattern are described as fulfilling a mediating role within the triad similar to the Supervising Controller pattern. Views receive the initial events generated by the user and decide which actions to delegate to the Controller. For this reason, the HMVC pattern is more similar to the Dolphin MVP pattern than with either the original Model-View-Controller or Presentation-Abstraction-Control patterns.

Pattern Comparisons

 The following chart presents a quick comparison of the components represented in the various patterns presented in this article with a brief description of its role within the architecture.

Pattern	Domain	Presentation	Control
Smalltalk-80 Model-View-Controller	Model - domain objects within an application	View- Visual presentation to the user	Controller - human to Model connector; Intercepts user input
Taligent Model-View-Presenter	Same as above	Same as above	Presenter - subsystem component connector; manages application subsystems
Dolphin Model-View-Presenter	Same as above	Same as above	Presenter - presentation to domain connector; manages access to Model updates
Passive View	N/A	Same as above	Controller – manages presentation logic
Supervising Controller	N/A	Same as above	Controller - assists with presentation logic
Presentation-Abstraction-Control	Abstraction - domain objects within an application	Presentation – interactive component within the application	Control - Presentation to Abstraction connector

 

Conclusion

The Model-View-Controller, Model-View-Presenter, and Presentation-Abstraction-Control patterns are similar in many ways, but have each evolved to address slightly different concerns. By becoming familiar with these patterns and other related architecture models, developers and architects will be better equipped in choosing an appropriate solution in their next design endeavor, or possibly in the creation of future architecture design patterns.

 

 

References

1. Reenskaug, Trygve. The original MVC reports. Trygve Reenskaug Home Page. [Online] May 12, 1979. [Cited: July 07, 2007.] http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf.

2. Steve Burbeck, Ph. D. Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC). The UIUC Smalltalk Archive. [Online] March 4, 1997. [Cited: July 7, 2007.] http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.

3. Potel, Mike. [interv.] Derek Greer. July 18, 2007.

4. Reenskaug, Trygve. The Model-View-Controller (MVC) Its Past and Present. Trygve Reenskaug Home Page. [Online] August 20, 2003. [Cited: July 7, 2007.] http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf.

5. Fowler, Martin. Patterns of Enterprise Application Architecture . s.l. : Addison-Wesley Professional, 2002. 978-0321127426.

6. PAC, an Object Oriented Model for Dialog Design. Coutaz, Joëlle. [ed.] H-J. Bullinger and B. Shackel. North-Holland : Elsevier Science Publishers, 1987. Interact'87.

7. Calvary, Gaëlle, Coutaz, Joëlle and Nigay, Laurence. From Single-User Architectural Design to PAC*: a Generic Software Architecture Model for CSCW. [http://www1.acm.org/sigs/sigchi/chi97/proceedings/paper/jcc.htm] Grenoble, France : s.n., 1997.

8. AMODEUS-2 - Multidisciplinary HCI Modelling. http://kmi.open.ac.uk. [Online] 1997. [Cited: August 20, 2007.] http://kmi.open.ac.uk/people/sbs/amodeus.html.

9. Nigay, L. and Coutaz, J. Software Architecture Modelling: Bridging Two Worlds Using Ergonomics and Software Properties. http://iihm.imag.fr/. [Online] [Cited: August 20, 2007.] Software Architecture Modelling: Bridging Two Worlds Using Ergonomics and Software Properties.

10. Sheppard, Sylvia. REPORT ON THE CHI '91 UIMS TOOL DEVELOPERS' WORKSHO P. SIGCHI Bulletin. January 1992, Vol. 24, 1.

11. Coutaz, Joëlle. Correspondance with Joëlle Coutaz. [Email]. August 20, 2007.

12. Fowler, Martin. GUI Architectures. www.martinfowler.com. [Online] July 18, 2006. [Cited: July 03, 2007.] http://www.martinfowler.com/eaaDev/uiArchs.html.

13. —. Supervising Controller. www.martinfowler.com. [Online] June 19, 2006. [Cited: July 03, 2007.] http://www.martinfowler.com/eaaDev/SupervisingPresenter.html.

14. —. Passive View. www.martinfowler.com. [Online] July 18, 2006. [Cited: July 3, 2007.] http://www.ibm.com/developerworks/java/library/j-mvp.html.

15. Potel, Mike. MVP: Model-View-Presenter - The Taligent