|
J2EE的Web和企业架构（WEA）设计模式 |
作者：佚名 发布时间：2005-04-02 来源：不详
|
由于GoF（Gamma, Helm
专家们找到了一个新的强有
描述一个反复出现的问题，
无须再做重复劳动。”一般
题，解决方案和使用带来模
|
s, Johnson, and Vlissides）
力的设计方法。什么是设计模式
以及解决这个问题的方案的核心
来说，一个设计模式包括四个基
式的效果（或后果）。
|
的设计模式的广发普及，软件工程
？他们这样定义：“设计模式就是
。你可以重复使用这个解决方案而
本要素：模式名称，需要解决的问
|
在GoF中描述的设计模
应用设计领域已是人人皆知
一样起着相当重要的作用。
节省工作量是可以用人小时
|
式,诸如Factory Method, Obser
，家喻户晓。正像编者在先前说
在设计会议中人们使用设计模式
估算出来的。
|
ver, Façade等，在现在的
的那样，设计模式的命名与描述和
的命名比使用他们枯燥乏味的描述
|
这本书出版七年以后，
了一些设计模式，但远远不
计模式能达到最初的那23种
式的边际效用几乎趋近于零
|
我们发现设计模式大致和从前是
及起初GoF的提出设计模式集合
设计模式的普及和声望。借用经
。因此设计模式科学是无非是一
|
相对一致的。尽管后来也有人增加
价值高。经试验证明，没有一个设
济学的一个术语来说就是，新的模
个一次性思想的静态集合。
|
正相反，从一个Web领域应用程序设
意也可以叫模式）事实上是无法实施在应
需求，同样的方式，最初的设计模式就能
|
计者的经验来讲，我们发现一些历史经验（如果你愿
用程序级或子系统级上实现一套指定的方法集这样的
完成这种低级别功能标准化的需求。
|
接下来我们讨论的内容其实也不是什
的并经常使用的简单，标准，通用的方法
的方法分类和命名，希望可以使用这些命
证明它们是非常有价值的。我们把它们命
Enterprise Architecture Design Patte
计模式的宏观命名。
|
么新东西。它们是一些许多有经验的开发人员所知道
。仿照最初设计模式集的方式，我们对这些显而易见
名（通过生动地捕捉这些方法的基本功能获得的）来
名为“Web和企业架构设计模式（Web and
rns）”，简称“WEA设计模式”一个应用程序级的设
|
作为一个J2EE的热衷者
概念对其他技术也还是相当
引人的想法，但是确实存在
SmallTalk是非常有用的，
好的解决了这些问题。）
|
，我们仅仅关注与Java相关的问
有帮助的。（难道设计模式不是
争论，如GoF的模式Abstract Fa
而对Java来说是多余的。因为Ja
|
题和解决方案上，尽管这样，许多
独立于语言的吗？这是一个相当吸
ctory and Prototype对C++和
va的Class类和类的反射机制非常
|
回想GoF，它把设计模式分为三类，
Structural）, 和 行为（Behavioral）
|
通俗易懂，便于记忆：创建（Creational）,结构（
。
|
秉承这一优良传统，我
全（Security），导航（Na
是一个详尽列表，而仅仅是
|
们把我们的模式分为划分（Part
vigation）和数据量控制（Data
最初的感觉比较适当的模式类型
|
itioning）,作用域（Scope）,安
Volume Control）五类。这并不
集。
|
我们粗略地使用GoF建
个大标题。在“意图（Inte
题和方案（Problem and So
“效果（Consequences）”
|
立的描述结构来描述我们的模式
nt）”标题下，我们用一行陈述
lution）”标题下阐述要解决的
标题下详尽论述使用此模式带来
|
。为了简便，我们将压缩处理为三
使用这个模式的意图。我们在“问
问题及其解决方案。最后，我们在
的积极和消极的因素。
|
为了简洁，我们也省去
也省去了Java代码样例。我
|
UML类图描述。我们的模式是相
们相信大多数J2EE开发人员都能
|
当简单，并不需过多的描述。我们
明白这些模式。
|
| 划分模式（Partitioning Patterns） |
在应用程序中，客户端（浏览器）和
服务器通过服务器端脚本语言如Java或PH
逻辑分开。
|
服务器都能执行逻辑，客户端通过javascript完成，
P执行。但由于各种原因应该把这两个层中应用程序
|
| 问题和方案（Problem and Solution） |
许多应用程序采取一种避免使用java
|
script的策略。一个非常普遍的原因就是当用户
|
当关掉浏览器的支持ja
员开发时还需要考虑对浏览
，但是这种考虑并没有消除
|
vascript功能时，应用程序就不
器不同版本的支持。（尽管现在
）
|
能正常的运转了。还有就是开发人
许多浏览器都改善了对w3c的兼容
|
如果有这些的原因其中
的属于前台的，而且使用ja
电子商务应用程序在服务器
|
一种，我就必须把所有的处理放
vascript非常容易实现的操作也
端计算总数，尽管计算所需的信
|
到服务器上完成。即使是非常简单
要放到服务器上执行。例如，许多
息都在客户端。
|
| 使用哑客户端模式给应用程序带来的好处就是可以在任何版本浏览器上运行，包括老以 |
| 前的版本。可以相当好的支持安全要求，不允许用户执行任何客户端脚本。 |
使用这个模式的短处就是增加了网络
不良的影响，尽管这种影响我们可以在用
地执行之后，操作会变得粗糙不流畅，使
|
传输和服务器的负载。这可能对应用程序的性能造成
例级精确地评测出来。除此之外，许多操作不支持本
应用程序交互性变差，不友好。
|
| 2． 独立客户端（Independent Client） |
| 问题和方案（Problem and Solution） |
现在大多数Web应用程
javascript执行本地的表单
理。客户端和服务器代码单
|
序都是客户端和服务器都需处理
验证来提高交互能力，服务器执
独编写，这样可能造成在两个层
|
逻辑的智能混合体。客户端使用
行一些需要和后台交互的请求的处
中一定程度的代码冗余。
|
使用独立客户端模式的
互在很短的响应时间内就完
|
优点就是使应用程序更自然，更
成。网络传输降到最小，服务器
|
舒服。许多操作可以不和服务器交
负载降到最小。
|
使用此模式的缺点就是使两个层之间
的验证更友好，因为它的更易给用户快速
能依靠前台验证，后台必须执行自己的验
常和错误，尤其是在维护阶段逻辑发生变
我们掉入陷阱。
|
逻辑代码造成冗余。例如客户端的验证要比服务器端
反馈。但它并不能代替服务器端验证，因为后台并不
证来保证不被错误数据侵害。这种冗余可能会造成异
化的时候。由于Java和javascript的差异很可容易使
|
| 3． 改良服务器客户端（Server-Modified Client） |
| 问题和方案（Problem and Solution） |
有时，客户端的处理需
取出来放到一个数据结构中
要每次都去和服务器交互一
要访问的数据了。例如，动
数据库获得数据组装成的一
|
要一些存储在数据库或后台的数
，当javascript需要时，就可以
次。这样一旦一个页面被载入，
态和有条件的装配一个下拉框，
个数组完成。
|
据。应用程序可以预先把这些数据
轻松的访问这个数据结构，而不需
客户端操作就可以迅速的访问他想
javascript就可以访问使用从后台
|
一些更复杂的应用程序可能需要后台
验证。
|
来生成javascript函数。例如，用服务器控制客户端
|
改良服务器客户端模式
变化。并不是用于生成HTML
辑，如有条件生成的HTML导
|
目的是为了处理javascript代码
元素，那是JSP的基本功能。（
航元素）
|
和使用Web层Java代码数据结构的
当然，灰色域也是一种隐式商业逻
|
使用改良服务器客户端
制客户端和服务器端逻辑成
|
模式的优势就是，在没有冗余的
为可能。两个层之间的异常得以
|
情况下达到良好交互。使在一点控
减少或消除。
|
使用这一模式的劣势在于增加了复杂
成这些代码的代码，复杂程度一般会增加
|
度。因为生成javascript代码是相对简单，而维护生
一个数量级。
|
作用域一般指一些信息
（Request）、会话（Sessi
|
的生命周期，经验告诉我们，我
on）和关系（Relationship）。
|
们遇到的作用域有下面几种：请求
|
一个请求作用域变量在客户端请求返
登陆到会话未结束之前一直可以访问。最
个用户的详细资料，这个变量就一直存在
，而是根据现实中抽象出来的，诸如个性
Application这两个作用域）
|
回之前都是可以访问的。一个会话作用域变量从用户
后，一个关系作用域变量，只要在应用程序中存在这
。关系作用域并不是JSP规范定义的一种作用域类型
化。（我们并不去过多考虑JSP定义的Page和
|
| 在多步骤的服务器端处理中，提供对请求作用域变量的统一访问的机制。 |
| 问题和方案（Problem and Solution） |
大多数Web开发的初学者会发现JSP的
HttpServletRequest对象的getParameter
来传去时，在Web层进行一系列操作变得
修改，而缺少setParameter()方法，这将
|
一个残酷而又明显的缺陷之一就是没有一个像
()方法一样的设置器。这样就可能使请求在组件间传
特别头疼。有些操作可能还需要请求作用域变量进行
会变得极其糟糕。
|
请求对象的用于处理指
一个指定字符串)和setAttr
个新来自浏览器请求对象中
|
定对象的getAttribute()(与get
ibute()给了我们一线希望。可
获得参数是无效的，还必须调用
|
Parameter()方法相比，它将返回
是，使用getAttribute()方法从一
getParameter()方法。
|
请求访问器模式被设计
管理。更简单的说，这个模
buteOrParameter()方法）
getAttribute()方法，如果
用域的服务器端组件都可以
当这个变量是被改变了又放
请求访问器，就可以找到最
数都是字符串，而所有的字
字符串进行造型就可以了。
|
为，使用一个兼容的接口来对请
式就是，工具类的一个静态方法
，用于查找指定的HttpServletR
什么都没找到，就调用getParam
使用这个方法。可以就迅速的一
到请求对象中的话，必须先调se
新的被修改过的参数，而不是最
符串都是对象，当要检索的对象
|
求对象的检索、存储和重检索进行
（可以叫getAttri
equest对象。先调用
eter()方法。任何需要检索请求作
次性访问到从浏览器传来得参数。
tAttribute()方法，然后，再调用
初的原始数据。由于被传过来的参
时，只要在请求访问器找到后，对
|
（在multi-part类型的表单中，当请
重造，过程相当复杂。这样导致所有的请
用session对象（小心使用！！）把请求
情况的方法。）
|
求从一个传到另一个组件时，请求对象可能被扔掉并
求作用域的变量被丢失。例如，在这种情况就可以使
作用域变量传给组件。请求访问器也必须考虑到这种
|
使用请求访问器模式的优遇就是提供
简单方法。例如Struts。
|
一个在服务器端多步骤处理中访问请求作用域变量的
|
| 使用这一模式的缺憾就是要尽量避免使用属性名而带来的冲突。 |
| 把应用程序的状态管理从以Web为中心的机制中独立出来。 |
| 问题和方案（Problem and Solution） |
大多Web应用程序对ses
作用域变量的。尽管这样，
人们更喜欢来维护客户端和
状态。这个方式使增加通道
音响应），而无需复制维护
Web层水平负载平衡方案更
个比较新的技术，好多旧的
|
sion的状态维护都是使用JSP引
多通道应用程序还是尽可能避免
应用程序服务期间点对点的状态
变得更加容易（例如IVR（Inter
状态逻辑。也有利于避免Web会
加容易实现，使用一个循环实现
JSP引擎并不支持。）
|
擎的隐式session对象来保存会话
和以Web为中心的机制缠在一起。
。使中间Web层（JSP引擎）保持无
active Voice Response）-交互声
话和物理JSP引擎之间的耦合。使
而不是使用簇。（簇相对而言是一
|
无状态通道模式利于多
序服务器产生一个会话符号
号串，在HttpSession对象
用表单隐藏变量的形式或在
提交或链接被使用时，会话
，接着被传回到应用程序层
状态就被点对点维护，一种
|
通道应用程序中会话作用域变量
串，通过Web层传到客户端（如
也不存，其他任何地方都不存储
一个超级链接中的一个get参数
符号串会被传回Web层，Web层就
验证，并检索会话作用域变量（
与通道完全独立的方式。因此命
|
的管理。当验证成功之后，应用程
浏览器），Web层并不存储会话符
会话符号串。客户端（浏览器）使
来暂存会话符号串，这样，当表单
可以处理它，（本地并不存储它）
和关系作用域变量）。这样，会话
名为无状态通道。
|
使用无状态通道模式的
多通道应用程序。也可以通
力的通道层。
|
最大优点就是可以不必给每个通
过简单的负载平衡方案（如循环
|
道层重新开发状态管理就可以建立
）来实现一个具有水平比利缩放能
|
使用这一模式的主要缺
需求。一个纯粹的Web开发
|
点是增加了复杂度，还有使用会
者可能很难习惯这种方式。
|
话对象时为避免冲突而进行的额外
| |
| |
|
|
|
