Interactive Application Architecture Patterns

On August 25, 2007, in Uncategorized, by derekgreer

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 patternrsquo;s implementation details are often incorporated into 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 addressing complexities inherent to the host platform. Todayrsquo;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, an 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. Within many development environments, the original goals of the Model-View-Controller pattern can be accomplished today by merely separating an applicationrsquo;s Forms and associated Controls from its domain model. The formalizing 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 isnrsquo;t adequately 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 a misappropriation 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 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, scores of competing constructs arenrsquo;t generally found purporting to address the same concern. 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.

Itrsquo;s best to think of architecture patterns as being as much in the realm of art as science. Interactive architecture patterns arenrsquo;t the computer science equivalent of Newtonrsquo;s Law of Gravity. They merely represent our ever evolving attempt to apply the best approach for application development.

Finally, when considering use of these patterns remember that their application should be considered for their applicability to the problem, not so one can proudly proclaim: “I use the such-and-such pattern”. Use of design 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 in order to use the pattern.

The Model–View-Controller Pattern

Overview

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

Origins and Motivation

The MVC pattern was originally conceived in 1978-79 by Trygve Reenskaugand 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. Reenskaugrsquo;s design was later implemented as part of the Xerox PARCSmalltalk-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 fu

剩余内容已隐藏，支付完成后下载完整资料

富交互应用架构模式

概述

MVC/MVP/PAC这三种架构分别从自己的角度通过把App的关注点划分到不同的模块来强调交互型App设计的必要性。大体上他们都差多，但是在设计动机和适应的设计目标上还是有稍微差别。这篇文章介绍了这些模式及相关历史，和一些设计动机以便更好的理解和运用这些模式。

为了更好的讨论这些架构，有必要知道很多架构的设计是源于当时的特定的开发环境的。由此，平台的特定动机和架构的实现细节也会夹杂在架构的描述中。比如，MVC的主要设计动机是把表现层从领域逻辑分开。输入和输出的分离（在原始的MVC中，Controller负责输入，View负责输出）是由于开发平台的复杂性导致的一个副产品（导致了Controller概念的产生）。现在的开发平台已经帮助开发者做了很多，屏蔽了很多底层的复杂性，在App级别实现输入输出分离已经没有意义。在这样环境中，一个MVC架构的App，可能会遵循它原有的思想，但是不会遵循它原有的形式，也可能是遵循了它原有的形式却抛弃了它原来的设计思想。在很多开发环境中，可以通过把应用的Forms/Controls和DomainModel 分离来实现MVC的思想。一个正式的用来处理用户输入的Controller在这些已经系统支持的平台是不需要的（译:比如处理一些键盘鼠标事件）。如果尝试在这些平台上实现原始的MVC，一个严格的MVC可能会和系统环境冲突也可能会给原有的组件强加上不同的责任，而这注定无法实现。从这个角度可以看出MVC并不足以提炼成一种模式语言。MVC中描述的模块（M-V-C）并不知道未来的开发环境是什么样子，并且大部分描述并不明确。所以经常会导致很多误解。

另一个建议是在学习和考虑是否使用某种交互设计架构的时候一定要抱着怀疑的态度。好多基本的模式，比如在Gamma的著作“Design Patterns - Elements of Reusable Object - Oriented Software”提到的模式，是对一些常见问题提炼出来的，是对具体实现无知的。由于这些模式的特性，他们并不会用来解决同样的问题，所以无法比较优劣。然而，在使用多种模式联合解决问题的场景，比如交互性应用架构，模式(patterns)、模型(models)、风格（styles）等等，这种研究就像读一篇关于飞行器历史的文档。

图1-1 airplane history

把架构设计和艺术相比再好不过。交互架构设计并不是牛顿万有引力定律那样的计算机科学。他们仅仅代表了我们过去不断演进的关于App开发的最佳实现。

最后，当开始考虑使用某种模式的时候需要记得的是这种模式对于问题的适用性，而不是自豪的宣称：“我用了XXX和XXX模式”。使用某个设计模式是由于对于某个问题，之前已经有某个模式可以很好的解决它了，而不是为了模式而模式。

MVC架构

简介

Model-View-Controller 是一种把应用分离成领域、呈现、和用户输入的几种模块的方法。

2.1 起源和动机

在1978-79年，MVC最早被 Trygve Reenskaug 构想并提出，最早的设计目标是提供一个可以让用户像操作真实世界中的实体一样的接口来操作views背后的数据。在 Reenskaug 和 他的同事更名为MVC之前它的名字叫Thing-Model-View-Editor。基于Reenskaug博士的设计，一个稍微修改的版本被应用于 XeroxPARC的Smalltalk80类库。这个版本的描述，可以参考： Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC)。

2.2 结构

下面的图示描述了 MVC 模式的架构：

图 2-2 mvc架构图

2.3 组成

Model指的是App的数据(data)和业务(business)逻辑。通常通过领域模型(DomainModel)来实现，领域模型的对象用来模拟真实世界的实体 - 描述他们的属性和行为。

View是model可视化的描述，通常是由应用程序中的界面(screen)和UI组件(widget)构成。

Controller是用来接收用户输入的组件，这些输入包括数据入口、键盘/鼠标命令。它的责任是桥接用户和应用，以便用户可以和屏幕及数据交互。

2.4 联系

在MVC模式中，可以被用户操作的每一个UI元素都对应一个Model-View-Controller三元组。

Model代表将被用户看到并操作的数据状态、结构、行为。Model不会直接的持有View或者Controller的引用，但是可以被View、Controller或系统中得其他元素改变。如果View/Controller需要被通知数据变化，那么可以使用Observer Pattern来发送通知。

View和Controller组件一起工作来方便用户查看Model并与之交互。每个View都和一个单独的Controller配对，每个Controller也都唯一的关联一个View。View和Controller都持有一个指向Model的引用。

注意：在 Smalltalk80 实现中，View和Controller相互持有对方的引用，但是从View到Controller的引用完全是一个实现上的问题，并不是MVC模式的规范。这个引用并不是像接下来要讨论的MVP那样，用来把用户输入委托给Controller处理，而是用来让view在自己的实例内初始化Controller组件，并让上一层的Controller方便的定位View结构化组织中的其他Controller。

View的责任主要用来处理输出，而Controller的责任主要用来处理输入。和Model的交互是它们共有的责任。Controller和Model交互，以便响应用户输入，而View和Model交互是用来更新自己的状态。需要的时候它们都可以访问并修改Model的数据。

当用户输入数据的时候，Controller会拦截用户的输入做出合适的响应。有些用户动作会导致和Model交互，比如修改数据或者调用方法，有些用户动作会导致view的变化，比如折叠菜单或者高亮滚动条等等。

2.5 MVC的误解

一个常见的误解是Model-View-Controller三个模块之间的关系是Controller用来分离View和Model。尽管MVC模式确实分离了应用领域层和表现层，但是这是通过观察者模式完成的，而不是Controller。Controller是用户和应用之间的中介，而不是用来分离View和Model的。

2.6模式变化和衍生

经典的MVC架构的原有形式已经不再被使用了，但是它启发了很多适应于新的开发平台的新的变种。

WEB 应用程序中MVC模式

3.1 简述

自从Web的出现，模仿早期MVC架构的设计开始被应用于Web应用中。和早期的MVC一样，Web-basedMVC 模式也旨在分离应用的领域（domain）、客户端呈现(client-side presentation)和服务器端输入处理。

3.2 起源

Web端的MVC起源是由于面向对象的设计被应用于无状态的HTTP协议和HTML视图表现。Web应用通过服务器模块(server-size)处理输入的HTTP请求来给用户端(web-client)提供动态内容。随着不同的Web开发模式的出现，处理和路由HTTP请求的需求已经变成一个基本功能，这些代码的逻辑目标和当初的Smalltalk80的Controller是一样的 - 响应终端用户的输入来引导应用的行为。基于文本的HTML也导致了一种通过模板的方式来分离应用的内容和逻辑（特别是本地化的应用）。当这些技巧被应用于面向对象的应用开发环境中时，一个类似于早期的MVC架构的模式诞生了。

这种模式最终和java的“Model2”架构关联了。从90年代中期到晚期，Web应用主要是使用 “Common Gateway Interface(CGI)” 标准开发的，CGI应用在处理进来的HTTP请求时，可以在独立的进程中执行编译过的或解释过的代码。在1997年，SunMicrosystem公司发布了JavaServlet 1.0 标准来改进基于CGI的web应用开发，主要是把HTTP请求放在JVM提供的单独线程中来处理。在1999年，Sun更进一步在原有的框架基础上引入了 JSP(JavaServerPage) 1.0 标准。这个概念和微软在1996年11月份提出的 ASP(Active Server Pages) 类似。JSP 在Servlets的创建上提供了一层抽象，可以让开发者创建特殊的可以嵌入Java代码（scriptlet）的模板文件，这些代码会在被访问的时候编译到Servlet中。JSP标准的第一份草稿提供了两种使用这种技术的方案。第一种方式是一种Model-View分离的方案，请求会被直接路由到某个JSP，接下来它会和应用的model交互（在Java中叫“JavaBeans”）。第二种方式主要应用于比较复杂的情况，它是一种Model-View-Controller分离的方案，请求会先被路由到某个Servlet，接着它会和Model交互，然后会把控制权转交给JSP来渲染页面。在JSP标准草案的一次更新中把前者叫做Model1，后者叫做Model2。在这份标注中并没有提到关于 Smalltalk80-MVC的任何信息，它们的相似性是在 “Java World” 杂志同年11月份发布的一篇文章中被提出的，指出Model2架构可以被看做是服务器版的 MVC 架构实现。

虽然最早是Sun通过Model2架构引入的，但是Web版本的MVC架构被主流人群接受要归功于Craig R. McClanahan 创造的 Struts framework 框架，他在2000年6月的时候把这个框架捐献给了Apache基金会。Structs 作为一个MVC框架自从发布以来在Java社区中就被广泛的使用，并且由此催生了众多的web框架。

3.3 结构

虽然没有权威的架构存在，但是下图描绘了在web开发中典型的MVC：

图3-1 mvc for web

3.3组成

在Web应用中，一个称作 Front Controller 的Controller经常会被引入来处理一些常见的基础的事物，并且负责分发不同的请求到各自的Controller。在Java中通常由一个Servlet实现，在ASP中通常由IHttpHandler实现。典型的基础事物有，安全(security)、会话状态管理(session state management)、Controller的依赖注入方案(dependency injection resolution of the handling Controller)。

和Smalltalk80的MVC一样，Model封装了数据和应用的业务逻辑，通常由一个领域模型(DomainModel)来实现。

在Web应用中，View 是返回给浏览器的内容 - 通常是HTML和相关脚本。根据不同的实现，Views 可能是基于文本的模板 - 通过View模块渲染出来，也可能是从模板中编译出来的对象 - 它包含了会被渲染的内容。

和原始的Smalltalk80系统类似，Controller模块用来处理用户输入。不同的是输入不是来自像鼠标键盘之类的硬件设备而是HTTP请求（或者是从请求中解析出来的信息 - 依赖于具体实现）。

3.4 联系

在接收到一个HTTP请求的时候，前置Controller(Front Controller) 会先执行一些通用逻辑，然后通过这里拿到的信息再把请求路由到相应的Controller。一旦一个Controller被路由到，那么接下来请求会被委托给它做进一步处理。

一旦Controller收到了特定的请求，它会接着在Model上做一些操作然后把控制权移交给View。

由于Web应用是没有状态的，View 在每次请求的时候都会被重新渲染。所以在更新View的时候没有使用观察者模式（ObserverPattern）。为了在合适的状态渲染View，Controller通过一种类似