K
kidneyball
Unregistered / Unconfirmed
GUEST, unregistred user!
Web Presentation (Web表达)
最近几年，在企业应用系统领域中的一个最重大的变化是：基于浏览器的用户界面的越来越流行。它们带来了许多好处：不用安装客户端软件、具有统一的UI方法、还有简易的多用户访问。而且，有许多工具和环境使得开发一个web应用程序更为容易。
WEB应用程序的准备工作是从服务器软件开始的。通常，它以某种形式的配置文件来指定某个特定的URL会由哪个程序处理。通常一个单一的WEB服务器能处理多种类型的程序。这些程序常常是动态的而且能方便的添加到服务器——通过把它们放进一个合适的目录里。这些WEB服务器的工作是解释一个请求的URL的，然后把控制权交给WEB服务器程序。把程序放入WEB服务器的形式有两种形式：作为SCRIPT或者作为SERVER PAGE。
SCRIPT是一种程序，它通常包含了用来处理HTTP调用的函数或方法 - 例如CGI Script和Java servlet。这样，这些程序文本就能做到其他程序能做的事。而且这些script能够分解为子程序，并创建或者使用其他的一些服务。它通过检查HTTP REQUEST对象——实际上是HTML字符串——来从网页中获得数据。在一些情况下，它通过对文本字符串进行正则表达式搜索来达到同样效果——perl在这方面的易用性使得perl成为了开发CGI script的普遍选择。其他平台，例如Java servlets，为程序员完成了这类语法分析，这就使得script程序员能通过一个关键字的接口来访问request中的信息：这意味着我们只需要使用少量的难于处理的正则表达式。Web服务器输出的也是HTML字符串，RESPONSE。Script能使用普通的流写入操作来向它写入信息。
对程序员来说，通过流命令向HTML RESPONSE写入信息是很令人不快的。而且对那些非编程人员来说，几乎是不可能理解的，他们更乐意去看HTML网页。这就引入了服务器页面(Server page)的解决方案。在这里，程序文本被嵌入到要返回的HTML文本页面中。你使用HTML来编写需要返回的页面，同时把script程序代码嵌入到它们需要被执行的地方去。这类方案的例子有：PHP，ASP，和JSP。
当在response中只需要包含少量处理的场合下，server page方法工作得非常好，例如：“列出第1、2、3、4号CD专辑的详细资料”。但当你必须根据输入来做出判断的时候，使用server page就会变得非常复杂，例如要为经典乐曲和爵士乐曲CD专辑使用不同的输出格式。
因为script风格适用于解释request而sever page风格适用于格式化的response，我们就很容易做出一个明显的选择：使用script来解释request并使用sever page来格式化request。这种分离实际上是一种旧方法，它第一次是在Model View Controller模式中应用于用户界面上。把这两种方法与“应该把非可视的逻辑体现出来”这一基本意识结合起来，我们就能得到一个关于Model View Controller模式的非常恰当的概念。
Model View Controller是一个经常被人提到的模式，但却往往被误解。事实上在Web编程登上历史舞台之前，大多数我遇到的关于Model View Controller的描述都把它理解错了。造成这种混淆的一个主要的原因是使用了"Controller"这个词。Controller是一个与上下文相关的多义词，我在许多关于Model View Controller的描述中常常发现它的各种意义被混用在一起。因此，我倾向于使用input controller（输入控制器）这个术语来表达Model View Controller中的Controller.
（缺图）
图１：一个关于Model View 与Input controller怎样在Web服务器中扮演不同角色并协同工作的草图。 Controller处理request,请求Model处理业务逻辑，然后请求View生成一个基于Model的response
request首先进入一个input controller(输入控制器)。Input controller把信息从这个request中提取出来。然后，它把业务逻辑传递到合适的业务模型对象中。这个业务模型对象与数据源通讯，完成request中指示的所有事情，并收集生成response所需要的信息。当它完成之后，它把控制权交还给input controller。input controller根据返回的结果决定使用哪个view来显示这个response。然后，Input controller把控制权及response的有关数据一同交给选定的View。Input controller把控制权和数据传递给view的时候，常常并不是直接的调用，而是在传递中把数据以某种http session对象的形式存放在一个约定的地方，使得这个http session对象能被input controller与view共享。
应用Model View Controller最初的原因——也是最主要的原因——是保证Model完全从Web服务中分离出来。关于这一分离的好处，有一个很好的试验：问问你自己若要为你的程序增加一个新的命令行界面，需要对已有的代码进行多少改动？同时，把处理过程分离到一个独立的Transaction Script或Domain Model对象中也使得测试更加容易。当你使用server page风格来编写你的view的时候，这一分离会显得特别重要。
现在，我们来看看"controller"这个词的另一种用法。许多用户界面的设计看起来将presentation（表达）对象从domain（业务）对象中分离出来，在它们之间加入一个由Application Controller（应用程序控制器）对象组成的中间层。Application Controller是用来处理程序流程的，它决定哪个页面应以何种顺序显示出来。Application Controller可以作为presentation层的一部分，或者你也可以把它作为介于presentation与domain层之间的一个独立的层。在后一种情况下，Application Controller能被多个presentation重用。这适用于当你有一系列不同的presentation，而它们是基于相同的处理流程和导航方式的时候——虽然，在大多数情况下，更好的处理方法是为不同的presentation使用各自的独立处理流程。
并不是所有系统都需要Application Controller。它们仅仅在你的系统包含了大量关于页面显示次序的逻辑，以及需要在这些页面之间进行导航的时候才有用。如果你的程序被设计为用户可以以任何顺序打开任何页面，那么你很可能并不需要Application Controller.
View的模式
在View的方面，我们需要考虑三种模式：Transform View, Template View和Two Step View。基本上，这里有两重选择：一是选择使用Transform View还是Template View，二是对任何上述一种模式来说，是选择单步的View还是Two Step View。Transform View和Template View的基本模式是单步的。Two Step View是一种可应用于Transform View或Template View的变化模式
让我们先从Template View和Transform View之间的选择开始。Template View允许你以网页的架构来编写presentation，并在网页中嵌入标志来指示动态网页内容的连接。相当多流行的平台是基于这种模式的。而比这更加流行的，则是sever page技术（ASP, JSP, PHP)，它允许你在网页中加入完整的编程语言。显然，它提供了更多的功能和更好的弹性，可惜它同时会导致杂乱而且难以维护的代码。因此，如果你使用sever page技术，你就必须严格自律，保证把程序逻辑和网页结构明确地分离开来——这常常是通过使用一个伴随对象(原文：companion object)来实现的。
Transform View使用了一种变体的编程风格，XSLT就是一个常见的例子。当你使用XML格式或者能容易地转换成XML格式的业务数据的时候，这种方法能表现得非常有效。一个Input Controller选取合适的XSLT Stylesheet并把它应用在从业务模型中收集到的XML中。
如果你使用过程化的script作为你的view，你可以随便选择Transform View或Template View风格来编写你的代码——实际上，你甚至可以把它们结合起来混用。我注意到，绝大部分的script都遵从这两种模式中的其中一种作为它们的主要形式。
然后，我们需要在单步View和Two Step View中作出选择。
（缺图）
图2：Single Stage (单步) view
一个单步view模式几乎对应用系统中的每个界面(screen)分别使用一个view组件。这个view组件接受面向业务领域的数据，并把它修饰成HTML。我说“几乎”是因为逻辑相近的界面可能会共用一些view组件。但在大多数情况下，你可以认为这一模式是每个界面对应一个view组件。
（缺图）
图3：Two Stage View图
一个two stage view模式把这一过程分成两个阶段，首先把根据业务数据生成一个逻辑界面(screen)，然后把这个逻辑截面修饰成HTML。对每一个实际的界面(screen)，都有一个分别的第一阶段的view组件。但整个应用系统中只有一个第二阶段的view组件。
Two Step View的优点是它把关于“使用什么类型的HTML”的决定放到了一个单独的地方，这使得在全局范围内修改HTML更为容易——因为只需要改动一个对象，网站里的所有界面都会相应改变了。当然，这个优点的前提是你的表达逻辑是一致的（译注：主题化的），因此如果你的网站要为每一个界面使用同一基础布局的时候，这个模式工作得很好。然而高度偏向艺术化设计的网站则很难保证会有一个逻辑上一致的页面结构。
如果你有一个Web应用系统，而它的服务会被多个前端用户使用，那么就更能体现出Two Step View的优势，例如多个面向不同航线的前端使用同一个基础订票系统。在不超出同一个逻辑界面(screen)的条件下，每个前端都可以通过使用不同的第二阶段view组件来产生不同的外观
Input Controller的模式
Input Controller可以有两种不同的模式。在大多数普通情况下，你网站中的所有页面都分别使用一个input controller。在最简单的情况下，这个Page Controller可以是这个服务器页面(server page)本身：把view与input controller的角色合并在一起。但在许多具体实现中，把input controller分离到一个单独的对象中能使事情变得更为容易。这样的话，input controller能创建一个合适的业务模型来进行处理，并实例化一个view来返回结果。通常，你会发现Page Controller与view之间不总是一对一的关系。一个更为精确的看法是你为每一个action(行为控件)——例如一个超链接或一个按钮——准备一个Page Controller。大部分情况下，这些action是与页面一一对应的。但偶然也会有例外，例如一个会根据一些条件连接到几个不同页面的超链接。
每个input controller都有两方面的责任：处理http请求以及决定如何进一步处理。通常把这两个角色分开是有意义的。你可以使用一个服务器页面(server page)来处理http request，然后它委托另一个辅助对象来决定如何进一步处理。（译注：原文使用了handle与todo
with it，两个均译为处理，我的理解是handle表示进行简单的处理，例如接受请求，分离出参数等；todo
with表示响应这个请求进行的业务处理）Front Controller则更深化了这一分离：它只用一个对象来处理所有requests。这个唯一的处理部件对URL进行解释，从而知道在处理的是什么类型的请求，然后创建一个分离的对象来对其进行业务处理(process)。这就允许你用一个对象把所有http处理都集中起来，避免了当你改变网站的行为结构的时候需要重新配置服务器的麻烦。
相关读物
大部分关于Web服务器技术的书籍都提供了一到两章来阐述如何进行良好的设计——虽然这些内容常常被大量的技术描述所淹没。其中一个关于Java网站设计的很好的章节是[Brown et al]的第9章. 而关于其他模式的一个最好的资源是[Alur, Crupi, and Malks]，这些模式大部分能用在非JAVA的地方。而关于分别input controller与application controller的概念，我是在[Knight and Dai]里偷来的。
最近几年，在企业应用系统领域中的一个最重大的变化是：基于浏览器的用户界面的越来越流行。它们带来了许多好处：不用安装客户端软件、具有统一的UI方法、还有简易的多用户访问。而且，有许多工具和环境使得开发一个web应用程序更为容易。
WEB应用程序的准备工作是从服务器软件开始的。通常，它以某种形式的配置文件来指定某个特定的URL会由哪个程序处理。通常一个单一的WEB服务器能处理多种类型的程序。这些程序常常是动态的而且能方便的添加到服务器——通过把它们放进一个合适的目录里。这些WEB服务器的工作是解释一个请求的URL的，然后把控制权交给WEB服务器程序。把程序放入WEB服务器的形式有两种形式：作为SCRIPT或者作为SERVER PAGE。
SCRIPT是一种程序，它通常包含了用来处理HTTP调用的函数或方法 - 例如CGI Script和Java servlet。这样，这些程序文本就能做到其他程序能做的事。而且这些script能够分解为子程序，并创建或者使用其他的一些服务。它通过检查HTTP REQUEST对象——实际上是HTML字符串——来从网页中获得数据。在一些情况下，它通过对文本字符串进行正则表达式搜索来达到同样效果——perl在这方面的易用性使得perl成为了开发CGI script的普遍选择。其他平台，例如Java servlets，为程序员完成了这类语法分析，这就使得script程序员能通过一个关键字的接口来访问request中的信息：这意味着我们只需要使用少量的难于处理的正则表达式。Web服务器输出的也是HTML字符串，RESPONSE。Script能使用普通的流写入操作来向它写入信息。
对程序员来说，通过流命令向HTML RESPONSE写入信息是很令人不快的。而且对那些非编程人员来说，几乎是不可能理解的，他们更乐意去看HTML网页。这就引入了服务器页面(Server page)的解决方案。在这里，程序文本被嵌入到要返回的HTML文本页面中。你使用HTML来编写需要返回的页面，同时把script程序代码嵌入到它们需要被执行的地方去。这类方案的例子有：PHP，ASP，和JSP。
当在response中只需要包含少量处理的场合下，server page方法工作得非常好，例如：“列出第1、2、3、4号CD专辑的详细资料”。但当你必须根据输入来做出判断的时候，使用server page就会变得非常复杂，例如要为经典乐曲和爵士乐曲CD专辑使用不同的输出格式。
因为script风格适用于解释request而sever page风格适用于格式化的response，我们就很容易做出一个明显的选择：使用script来解释request并使用sever page来格式化request。这种分离实际上是一种旧方法，它第一次是在Model View Controller模式中应用于用户界面上。把这两种方法与“应该把非可视的逻辑体现出来”这一基本意识结合起来，我们就能得到一个关于Model View Controller模式的非常恰当的概念。
Model View Controller是一个经常被人提到的模式，但却往往被误解。事实上在Web编程登上历史舞台之前，大多数我遇到的关于Model View Controller的描述都把它理解错了。造成这种混淆的一个主要的原因是使用了"Controller"这个词。Controller是一个与上下文相关的多义词，我在许多关于Model View Controller的描述中常常发现它的各种意义被混用在一起。因此，我倾向于使用input controller（输入控制器）这个术语来表达Model View Controller中的Controller.
（缺图）
图１：一个关于Model View 与Input controller怎样在Web服务器中扮演不同角色并协同工作的草图。 Controller处理request,请求Model处理业务逻辑，然后请求View生成一个基于Model的response
request首先进入一个input controller(输入控制器)。Input controller把信息从这个request中提取出来。然后，它把业务逻辑传递到合适的业务模型对象中。这个业务模型对象与数据源通讯，完成request中指示的所有事情，并收集生成response所需要的信息。当它完成之后，它把控制权交还给input controller。input controller根据返回的结果决定使用哪个view来显示这个response。然后，Input controller把控制权及response的有关数据一同交给选定的View。Input controller把控制权和数据传递给view的时候，常常并不是直接的调用，而是在传递中把数据以某种http session对象的形式存放在一个约定的地方，使得这个http session对象能被input controller与view共享。
应用Model View Controller最初的原因——也是最主要的原因——是保证Model完全从Web服务中分离出来。关于这一分离的好处，有一个很好的试验：问问你自己若要为你的程序增加一个新的命令行界面，需要对已有的代码进行多少改动？同时，把处理过程分离到一个独立的Transaction Script或Domain Model对象中也使得测试更加容易。当你使用server page风格来编写你的view的时候，这一分离会显得特别重要。
现在，我们来看看"controller"这个词的另一种用法。许多用户界面的设计看起来将presentation（表达）对象从domain（业务）对象中分离出来，在它们之间加入一个由Application Controller（应用程序控制器）对象组成的中间层。Application Controller是用来处理程序流程的，它决定哪个页面应以何种顺序显示出来。Application Controller可以作为presentation层的一部分，或者你也可以把它作为介于presentation与domain层之间的一个独立的层。在后一种情况下，Application Controller能被多个presentation重用。这适用于当你有一系列不同的presentation，而它们是基于相同的处理流程和导航方式的时候——虽然，在大多数情况下，更好的处理方法是为不同的presentation使用各自的独立处理流程。
并不是所有系统都需要Application Controller。它们仅仅在你的系统包含了大量关于页面显示次序的逻辑，以及需要在这些页面之间进行导航的时候才有用。如果你的程序被设计为用户可以以任何顺序打开任何页面，那么你很可能并不需要Application Controller.
View的模式
在View的方面，我们需要考虑三种模式：Transform View, Template View和Two Step View。基本上，这里有两重选择：一是选择使用Transform View还是Template View，二是对任何上述一种模式来说，是选择单步的View还是Two Step View。Transform View和Template View的基本模式是单步的。Two Step View是一种可应用于Transform View或Template View的变化模式
让我们先从Template View和Transform View之间的选择开始。Template View允许你以网页的架构来编写presentation，并在网页中嵌入标志来指示动态网页内容的连接。相当多流行的平台是基于这种模式的。而比这更加流行的，则是sever page技术（ASP, JSP, PHP)，它允许你在网页中加入完整的编程语言。显然，它提供了更多的功能和更好的弹性，可惜它同时会导致杂乱而且难以维护的代码。因此，如果你使用sever page技术，你就必须严格自律，保证把程序逻辑和网页结构明确地分离开来——这常常是通过使用一个伴随对象(原文：companion object)来实现的。
Transform View使用了一种变体的编程风格，XSLT就是一个常见的例子。当你使用XML格式或者能容易地转换成XML格式的业务数据的时候，这种方法能表现得非常有效。一个Input Controller选取合适的XSLT Stylesheet并把它应用在从业务模型中收集到的XML中。
如果你使用过程化的script作为你的view，你可以随便选择Transform View或Template View风格来编写你的代码——实际上，你甚至可以把它们结合起来混用。我注意到，绝大部分的script都遵从这两种模式中的其中一种作为它们的主要形式。
然后，我们需要在单步View和Two Step View中作出选择。
（缺图）
图2：Single Stage (单步) view
一个单步view模式几乎对应用系统中的每个界面(screen)分别使用一个view组件。这个view组件接受面向业务领域的数据，并把它修饰成HTML。我说“几乎”是因为逻辑相近的界面可能会共用一些view组件。但在大多数情况下，你可以认为这一模式是每个界面对应一个view组件。
（缺图）
图3：Two Stage View图
一个two stage view模式把这一过程分成两个阶段，首先把根据业务数据生成一个逻辑界面(screen)，然后把这个逻辑截面修饰成HTML。对每一个实际的界面(screen)，都有一个分别的第一阶段的view组件。但整个应用系统中只有一个第二阶段的view组件。
Two Step View的优点是它把关于“使用什么类型的HTML”的决定放到了一个单独的地方，这使得在全局范围内修改HTML更为容易——因为只需要改动一个对象，网站里的所有界面都会相应改变了。当然，这个优点的前提是你的表达逻辑是一致的（译注：主题化的），因此如果你的网站要为每一个界面使用同一基础布局的时候，这个模式工作得很好。然而高度偏向艺术化设计的网站则很难保证会有一个逻辑上一致的页面结构。
如果你有一个Web应用系统，而它的服务会被多个前端用户使用，那么就更能体现出Two Step View的优势，例如多个面向不同航线的前端使用同一个基础订票系统。在不超出同一个逻辑界面(screen)的条件下，每个前端都可以通过使用不同的第二阶段view组件来产生不同的外观
Input Controller的模式
Input Controller可以有两种不同的模式。在大多数普通情况下，你网站中的所有页面都分别使用一个input controller。在最简单的情况下，这个Page Controller可以是这个服务器页面(server page)本身：把view与input controller的角色合并在一起。但在许多具体实现中，把input controller分离到一个单独的对象中能使事情变得更为容易。这样的话，input controller能创建一个合适的业务模型来进行处理，并实例化一个view来返回结果。通常，你会发现Page Controller与view之间不总是一对一的关系。一个更为精确的看法是你为每一个action(行为控件)——例如一个超链接或一个按钮——准备一个Page Controller。大部分情况下，这些action是与页面一一对应的。但偶然也会有例外，例如一个会根据一些条件连接到几个不同页面的超链接。
每个input controller都有两方面的责任：处理http请求以及决定如何进一步处理。通常把这两个角色分开是有意义的。你可以使用一个服务器页面(server page)来处理http request，然后它委托另一个辅助对象来决定如何进一步处理。（译注：原文使用了handle与todo
with it，两个均译为处理，我的理解是handle表示进行简单的处理，例如接受请求，分离出参数等；todo
with表示响应这个请求进行的业务处理）Front Controller则更深化了这一分离：它只用一个对象来处理所有requests。这个唯一的处理部件对URL进行解释，从而知道在处理的是什么类型的请求，然后创建一个分离的对象来对其进行业务处理(process)。这就允许你用一个对象把所有http处理都集中起来，避免了当你改变网站的行为结构的时候需要重新配置服务器的麻烦。
相关读物
大部分关于Web服务器技术的书籍都提供了一到两章来阐述如何进行良好的设计——虽然这些内容常常被大量的技术描述所淹没。其中一个关于Java网站设计的很好的章节是[Brown et al]的第9章. 而关于其他模式的一个最好的资源是[Alur, Crupi, and Malks]，这些模式大部分能用在非JAVA的地方。而关于分别input controller与application controller的概念，我是在[Knight and Dai]里偷来的。
