随笔 - 22  文章 - 0 评论 - 138 trackbacks - 19

Web展现

最近几年企业应用中最大的改变无疑是基于Web浏览器的用户界面的崛起。优势在于:不需要部署任何客户端软件,一致的UI使用方法,便利的全球访问。

通常Web服务器上有着各种各样的配置文件来确定哪些URL该由那个程序处理,一个Web服务器可以支持多种程序。它的工作只是解释请求(request)的URL并把控制交给服务器端程序。

服务器端程序基本上可以分为两种基本的类型:script和server page

script形式是一个程序,通常拥有处理请求的方法。如CGI和Java servlet。它们能做任何一个程序可以做的事情,可以分解成子程序,可以创建并使用其他的服务(service)。它通过分析HTTP请求对象来获取网页上的数据。由于HTTP请求对象是一个字符串,所以在某些环境中,如Perl,使用正则表达式来分析它,这也使得Perl成为了流行的CGI编程语言。另一些环境,如Java servlet,环境本身为程序员做了这些事情。输出是另一个称为HTTP响应(response)的字符串,只需用语言支持的write stream操作来写出就可以了。

通过流命令来输出HTML格式的响应是很不舒服的,对于非程序员来说更是不可能的,他们更乐意准备HTML页面。这导致了server page的诞生,用HTML格式来写输出页面,并在HTML中嵌入语言的小脚本,这些小脚本可以执行,并生成对应的HTML段落。包括PHP,ASP和JSP在内的技术都属于server page。

 server page方法在对响应只需要做一点点处理的时候工作的很好,但是更复杂的逻辑就会使它变得很复杂。

因为script形式用来处理输入很好,server page处理输出是强项,很明显可以用script来解释输入并用server page来处理输出。这样分割来源于Model View Controller模式。

Model View Controller模式是一个被广泛参考的,但也是最常被误解的模式。造成混乱的主要原因是"Controller"这个词的使用。Controller在很多语境中被使用,而且通常和Model View Controller中的意义不同。所以作者使用术语input controller来表示Model View Controller中的Controller。

input controller接收到一个请求,它从请求中取出信息,交给适当的领域类来处理。领域类从数据源中取出数据并处理请求中的信息,形成响应的数据。完成后将控制权交还给input controller,它检查结果并决定使用那个view来显式结果。然后它把控制权连同响应数据一起交给view。通常响应数据不是直接交给view的,而是放在类似HTTP session这种被input controller和view共享的地方。

使用Model View Controller模式的最主要的原因是要确保展现被完全分割。这样做使得修改展现和以后添加展现更加容易。将处理过程放进单独的Transaction Script或者Domain Model对象可以使得测试也更加容易。这点在你使用server page作为view的时候特别的重要。

第二种"controller":许多用户界面设计把展现对象和领域对象用一个中间层隔离开,这个中间层称为Application Controller。Applicaton Controller的主要功能是管理应用的流程。可以看作展现层的一部分,也可以看作是展现层和领域层的中间层。只有在你的系统有许多关于出现顺序和导航的逻辑的时候,才需要Application ControllerApplication Coltroller在你的页面和领域中的动作映射关系比较复杂是也有用。一个好的测试你是否需要Application Controller的方法:如果是机器控制流程,你需要它;如果是用户控制流程,你不需要它。

View模式

在view这边有三种模式需要考虑:Transform ViewTemplate ViewTwo Step View。你必须做两个选择,1:使用Transform View还是Template View。2:是否使用Two Step View

Template View允许你拥页面的结构来写展现并且嵌入占位符来表示哪儿需要动态内容。许多平台基于这种模式,它们中的许多使用server page技术(ASP,JSP,PHP),允许你在页面中放入完整的编程语言。这提供了灵活性和强大性,但是会不可避免的产生难以维护的代码。为了将你的程序逻辑和页面分开,经常需要使用helper object。

Transform View使用转换的方法,最常见的就是XSLT。如果你的领域数据是XML格式的,它会非常有效,非常容易转换。input controller使用适合的XLST样式表并把它应用到从领域类中得到的数据上。

如果你使用过程脚本作为你的view,你可以使用Transform View和Temlpate View中的任何一个,或者混合使用。

单步的View通常对于每一个场景有一个对应的View。有相似逻辑的场景可能共享View。

Two-stage view分为两步,第一步从领域数据中得到罗技场景,第二步把它渲染成HTML。对于每个场景有一个对于的first-stage view,但是总共只有一个second-stage view。优势在于它把决定使用什么HTML的工作放在单一的地方(second-stage)。这也如果需要修改HTML,只需修改一个地方就可以对所有的场景生效。

对于不同的客户使用相同的服务(如不同的航空公司,页面除了logo等之外大体都是相同的),two-stage view能工作的很好。对于不同的设备(如普通的web浏览器和移动设备的浏览器)使用不同的second-stage view也是一种可能的应用。

Input Controller模式

对于input controller有两种模式,最常见的就是每个页面有一个input controller对象。最简单的情况下Page Controller对象可以作为server page,把view和input controller合二为一。在很多环境中可以很简单的把input controller分离到单独的对象中。Page controller 和view也不一定是一对一的关系,page controller更可能是和动作一一对应。

Input controller有两种职责-接受HTTP请求并决定怎么处理它-分割它们是有意义的。一个server page可以接受请求,委托一个单独的助手对象来决定怎么处理它。Front Controller对象接受所有的请求,并创建对象来处理它。

posted on 2006-12-25 20:55 tmfc 阅读(...) 评论(...) 编辑 收藏