[
除了这两种模式，还有其它中庸的模式。Use Case Controller就是处于两者之间。只有和单个的用例相关的业务逻辑才放到对象中。所以大致上他们还是在使用Transation Script，而Domain Model只是Database Gateway的一组集合而已。我不太用这种模式。
Table Module是另一个中庸模式。很多的GUI环境依托于SQL查询的返回结果。你可以建立内存中的对象，来把GUI和数据库分开来。为每个表写一个模块，因此每一行都需要关键字变量来识别每一个实例。
Table Module适用于很多的组件构建于一个通用关系型数据库之上，而且领域逻辑不太复杂的情况。Microsoft COM 环境，以及它的带ADO.NET的.NET环境都适合使用这种模式。而对于Java，就不太适用了。
领域逻辑的一个问题是领域对象非常的臃肿。因为对象的行为太多了，类也就太大了。它必须是一个超集。这就要考虑哪些行为是通用的，哪些不是，可以由其它的类来处理，可能是Use Case Controller，也可能是表示层。
还有一个问题，复制。他会导致复杂和不一致。这比臃肿的危害更大。所以，宁可臃肿，也不要复制。等到臃肿为害时再处理它吧。
选择一个地方运行领域逻辑
我们的精力集中在逻辑层上。领域逻辑要么运行在Client上，要么运行在Server上。
比较简单的做法是全部集中在Server上。这样你需要使用html的前端以及web server。这样做的好处是升级和维护都非常的简单，你也不用考虑桌面平台和Server的同步问题，也不用考虑桌面平台的其它软件的兼容问题。
运行在Client适合于要求快速反应和没有联网的情况。在Server端的逻辑，用户的一个再小的请求，也需要信息从Client到Server绕一圈。反应的速度必然慢。再说，网络的覆盖程度也不是说达到了100％。
对于各个层来说，又是怎么样的呢？
基础架构层：一般都是在Server啦，不过有时候也会把数据复制到合适的高性能桌面机，但这是就要考虑同步的问题了。
表示层在何处运行取决于用户界面的设计。一个Windows界面只能在Client运行。而一个Web界面就是在Server运行。也有特别的例子，在桌面机上运行web server的，例如X Server。但这种情况少的多。
在例1中，没有更多的选择了，只能选在Server端。因此你的每一个bit都会绕一个大圈子。为了提高效率，尽量使用一些纯html脚本。
人们选用Windows界面的原因主要就是需要执行一些非常复杂的任务，需要一个合适的应用程序，而web GUI则无法胜任。这就是例2的做法。不过，人们应该会渐渐适应web GUI，而web GUI的功能也会越来越强大。
剩下的是领域逻辑。你可以全部放在Server，也可以全部放在Client，或是两边都放。
如果是在Client端，你可以考虑全部逻辑都放在Client端，这样至少保证所有的逻辑都在一个地方。而把web server移至Client，是可以解决没有联网的问题，但对反应时间不会有多大的帮助。你还是可以把逻辑和表示层分离开来。当然，你需要额外的升级和维护的工作。
在Client和Server端都具有逻辑并不是一个好的处理办法。但是对于那些仅有一些领域逻辑的情况是适用的。有一个小窍门，把那些和系统的其它部分没有联系的逻辑封装起来。
领域逻辑的接口
你的Server上有一些领域逻辑，要和Client通信，你应该有什么样的接口呢？要么是一个http接口，要么是一个OO接口。
http接口适用于web browser，就是说你要选择一个html的表示层。最近的新技术就是web service，通过基于http、特别是XML进行通信。XML有几个好处：通信量大，结构好，仅需一次的回路。这样远程调用的的开销就小了。同时，XML还是一个标准，支持平台异构。XML又是基于文本的，能够通过防火墙。
虽然XML有那么多的好处，不过一个OO的接口还是有它的价值的。hhtp的接口不明显，不容易看清楚数据是如何处理的。而OO的接口的方法带有变量和名字，容易看出处理的过程。当然，它无法通过防火墙，但可以提供安全和事务之类的控制。
最好的还是取二者所长。OO接口在下，http接口在上。但这样做就会使得实现机制非常的复杂。
Part 3 组织web Server
很多使用html方式的人，并不能真正理解这种方式的优点。我们有各种各样好用的工具，但是却搞到让程序难以维护。
在web server上组织程序的方式大致可以分为两种：脚本和server page。
脚本方式就是一个程序，用函数和方法来处理http调用。例如CGI脚本和java servlet。它和普通的程序并没有什么两样。它从web页面上获得html string形态的数据，有时候还要做一些表达式匹配，这正是perl能够成为CGI脚本的常用语言的原因。而java servelet则是把这种分析留给程序员，但它允许程序员通过关键字接口来访问信息，这样就会少一些表达式的判断。这种格式的web server输出是另一种html string，称为response，可以通过流数据来操作。
糟糕的是流数据是非常麻烦的，因此就导致了server page的产生，例如PHP，ASP，JSP。
server page的方式适合回应（response）的处理比较简单的情况。例如“显示歌曲的明细”，但是你的决策取决于输入的时候，就会比较杂乱。例如“通俗和摇滚的显示格式不同”。
脚步擅长于处理用户交互，server page擅长于处理格式化回应信息。所以很自然的就会采用脚本处理请求的交互，使用server page处理回应的格式化。这其实就是著名的MVC（Model View Controller）模式中的view/controller的处理。
odel View Controller模式首要的一点就是模型要和web服务完全分离开来。使用Transaction Script或Domain Model模式来封装处理流程。
接下来，我们就把剩余的模式归入两类模式中：属于Controller的模式，以及属于View的模式。
View模式
View这边有三种模式：Transform View，Template View和Two Step View。Transform View和Template View的处理只有一步，将领域数据转换为html。Two Step View要经过两步的处理，第一步把领域数据转换为逻辑表示形式，第二步把逻辑表示转换为html。
两步处理的好处是可以将逻辑集中于一处，如果只有一步，变化发生时，你就需要修改每一个屏幕。但这需要你有一个很好的逻辑屏幕结构。如果一个web应用有很多的前端用户时，两步处理就特别的好用。例如航空订票系统。使用不同的第二步处理，就可以获得不同的逻辑屏幕。
使用单步方法有两个可选的模式：Template View，Transform View。Template View其时就是把代码嵌入到html页面中，就像现在的server page技术，如ASP，PHP，JSP。这种模式灵活，强大，但显得杂乱无章。如果你能够把逻辑程序逻辑在页面结构之外进行很好的组织，这种模式还是有它的优点的。
Transform View使用翻译方式。例如XSLT。如果你的领域数据是用XML处理的，那这种模式就特别的好用。
Controller模式
Controller有两种模式。一般我们会根据动作来决定一项控制。动作可能是一个按钮或链接。所这种模式就是Action Controller模式。
Front Controller更进一步，它把http请求的处理和处理逻辑分离开来。一般是只有一个web handle来处理所有的请求。你的所有的http请求的处理都由一个对象来负责。你改变动作结构的影响就会降到最小.
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
