|
J2EE体系结构设计（2） |
作者：佚名 发布时间：2005-04-02 来源：不详
|
当底层的数据存储可能
对象；抽象代理的方法会创
理，每种对象对应一种持久
要使用的数据访问对象。
|
会变化的时候，开发人员可以采
建一些虚拟的数据访问对象代理
性存储介质的实现，一旦组件得
|
用抽象代理的方法来实现数据访问
和各种类型的实际数据访问对象代
到这些代理，就可以利用来创建需
|
图11给出了这种情况的
类，被其他一些实际的数据
实际的数据访问对象，并利
数据访问对象都负责建立对
|
类图。该类图表示了一个基础的
访问对象代理继承以支持特定的
用它来创建需要的数据访问对象
于数据源的连接，并得到和管理
|
数据访问对象代理，它是一个抽象
数据访问函数；用户可以得到一个
而访问相关的数据，每一个实际的
所支持的业务数据。
|
透明性好。业务对象可
细节被数据访问对象所隐藏
|
以在不知道数据源实现细节的情
，所以这种访问过程是透明的。
|
况下访问数据。由于一切数据访问
|
可移植性好。在应用系统中添加数据
种数据库实现上。业务对象与数据实现是
行一些变化即可。
|
访问对象，可以使得前者能够很方便地移植到另外一
隔离的，所以在移植过程中，仅仅对数据访问对象进
|
减少业务对象的代码复杂度。由于数
就简化了业务模块和其他数据客户的代码
|
据访问对象可以管理所有的数据访问复杂细节，这也
。同时也提高了应用系统的整体可读性和开发率。
|
集中处理所有数据访问
其他部分就与数据访问实现
得相关操作更加容易被维护
|
。由于所有的数据访问操作都移
隔离开来，而全部相关操作都与
和管理。
|
交给数据访问对象，这样应用系统
数据访问对象集中处理，这样也使
|
对于容器管理的持久性不能利用。如
性数据存储的管理都由容器负责。这样的
务将透明地提供这一功能。
|
果EJB容器采取容器管理的方式，那么所有对于持久
话应用系统就无需实现数据访问对象了，因为应用服
|
添加了额外的层面。数
一些额外的设计和实现的负
|
据访问对象在数据用户和数据源
担。当然，我们认为它是物有所
|
之间添加了一个层面，也就增加了
值的。
|
总之，在开发人员选择
比如说，与视图和显示相关
是与EJB层次相关的。另外
|
不同模式的时候，应该注意，一
的模式就是在Web层应用的。而
一些关于读取数据和分派操作的
|
定的模式对应于一定的应用层次。
一些与业务逻辑控制相关的模式则
模式则适用于不同的层次之间。
|
值对象(value object)
的通信是在Web层和EJB层之
关数据并提供给客户。
|
模式通过减少分布式通信的消息
间。在一个远程调用中，一个单
|
而促进数据的交换，通常这里所指
一值对象可以被用来取出一系列相
|
这种设计模式的出现是基于客户需要
台中，应用系统通常将服务器端的程序组
法则需要将数据返回给客户；这种情况下
到相关信息，应该注意的是，多数情况这
户名或者用户地址等。
|
与ejb大量地交换数据的情况。具体来说，在J2EE平
件实现为会话bean和实体bean，而这些组件的部分方
，通常一个用户会重复调用相关方法多次，直到它得
些方法调用的目的都是为了取得单一的信息，例如用
|
显而易见，在J2EE平台上，这种调用
应的方法会给Web带来极大的负担，即使
EJB程序，由于方法调用被缺省地认为是
|
基本上都是来自远程的。也就是说，用户多次调用相
用户和EJB容器加载相同的JVM、OS和计算机上运行
远程任务，所以这种问题依然存在。
|
由于以上所提到的问题
很大的下降，因此利用多次
究人员建议使用传输对象来
象；当用户向EJB发出对于
相关的数值，并将整个对象
|
，在远程方法的调用次数增加的
方法调用而取得单一的信息是非
包含所有的程序数据，即每次方
程序数据的请求时，EJB会创建
传送给用户。
|
时候，相关的应用程序性能将会有
常低效的；在这种情况，J2EE的研
法调用可以发送和接收这个传输对
这个传输对象，将它的各个域赋以
|
当EJB使用传输对象的
用多次方法调用以得到对象
以所有对于该传输对象的调
，这个传输对象必须具有对
|
时候，用户可以通过仅仅一次方
中每个域的数值；由于传输对象
用或取值都是本地调用，而不是
应于每个属性的访问方法，或者
|
法调用来取得整个对象，而不是使
是通过值传递而交送给用户的，所
远程方法调用。不过需要注意的是
将所有属性都设为公共的。
|
在图13中，传输对象首先在EJB中创
据需要融合其他的设计模式。
|
建，然后返回给远程客户；当然，传输对象也可以根
|
| 图14显示了传输对象模式中的参与模块和它们之间的交互。 |
(1)客户(Client)。客
程序。
|
户代表了EJB所提供服务的使用
|
者，通常是运行于用户终端的应用
|
(2)业务对象。业务对
Access Object)实现的角色
用户；业务对象也可以从用
新。
|
象表示在一个模式中由会话bean
。业务对象通常负责创建传输对
户中取得一个传输对象格式的数
|
、实体bean或数据访问对象(Data
象，并根据请求将其传送到相关的
据，并应用这些数据来执行一些更
|
(3)传输对象。传输对象是一个可序
包含所有域的构造函数，用来创建这个传
|
列化的Java对象。在这个对象的类中，通常会有一个
输对象。
|
这个传输对象中的成员
当然如果存在一定安全的需
方法。由此可见，传输对象
变量设为公共，或提供一定
|
变量基本都被定义为公共，从而
要，相关的成员变量也可以设为
的设计是随着应用系统的需要不
的访问方法，将是一个很重要的
|
无需为它们提供相关的访问方法。
保护或私有，并且给定各自的访问
同而改变的，是否将对象中的成员
设计问题。
|
通常在实现这个模式时，最多采取的
可更新的传输对象策略中，传输对象不仅
，还可以从业务对象中得到用户对于数据
|
是可更新的传输对象策略和多传输对象策略。 在
可以从服务于用户的业务对象中取得相关信息和数据
所需要进行的改变。
|
| 图15以类图表的形式表明了业务对象和传输对象之间的关系。 |
业务对象创建了传输对
据做出了一定的修改；为了
一定的变值方法，而出于对
相应地，这些方法可以去调
；同时在传输对象的方法中
务对象的方法得到传输对象
种本地数据访问不会影响到
|
象。而用户通过访问业务对象，
能够使得用户可以修改业务对象
Web负担的考虑，业务对象所提
用传输对象所提供的方法，来设
，我们也可以植入数据验证和完
时，可以直接调用传输对象的成
业务对象。
|
既得到了所需的信息，也对相关数
各个域的取值，这个对象必须提供
供的方法最好以传输对象为参数。
置传输对象的各个成员变量的取值
整性检查的逻辑，这样在用户从业
员方法进行本地数据访问，当然这
|
当用户调用业务对象的
业务对象；业务对象接收到
这里需要说明的是，上面提
我们需要在传输对象中另设
模式的设计相对复杂，开发
|
变值方法时，该方法会将用户端
更新的传输对象，便将这些更新
到的写回只是涉及到被更新的变
置一个变量，来指定哪些成员变
人员需要考虑同步化和版本控制
|
的传输对象序列化，再将它发送给
写回到自己的对象拷贝中去；
量，而不是全部变量的写回，因此
量被用户更新过，这也就使得这种
的问题。
|
多传输对象的方法是指一个单一的业
也就是说，业务对象和它所创建的传输对
各个参与模块以及它们之间的调用关系。
|
务对象可以根据用户请求制造多个不同的传输对象。
象保持一对多的关系。类图17表示了这种实现方法的
|
当一个用户需要A类型
象A；当他需要B类型的传输
序列图18表示了这一过程。
|
的传输对象时，他会激活相关EJ
对象时，他会激活getDataB()方
|
B的getDataA()方法来取得传输对
法来获取传输对象B；依此类推。
|
使用这种设计模式，应用系统的实体
再为每一个成员变量都实现一个set()和g
需再进行多次的方法调用来取得信息和数
。当然这里需要考虑Web负担和大量数据
择不同的实现方法。
|
bean及其远程接口会变得十分简单。实体bean中无需
et()方法，并在远程接口中实现相应的定义。用户无
据，所需要的只是一次方法调用以获得整个传输对象
一次传输的权衡。开发人员可以根据不同的需要来选
|
如上所述，用户和实体bean之间可以
据，也就是说传输对象作为数据载体工作
担。通过使用传输对象的方法，我们也将
过在使用可更新的传输对象方法时，用户
对象中，后者将所需的更新整合到自己一
不同的客户可能在同时修改相同类型的传
，可能就会造成一些用户的数据没有得到
在系统设计中必须考虑这个问题。
|
通过在一次方法调用中使用传输对象而交换所有的数
，并减少了远程的方法调用，从而大大减轻了Web负
有可能减少实体bean和其传输对象间的代码重复。不
可以修改其本地的传输对象，之后再将其传送回业务
端；但是这样一来，就会存在一个版本控制的问题，
输对象，而如果相关的业务对象没有发现这一点的话
及时更新，而另外一些用户的数据又被覆盖的情况；
|
截取过滤器(intercept
是说它对于客户的请求使用
求并提供一个核心的认证机
|
ing filter)主要用于对于用户
了额外的操作。比如说，servle
制。
|
请求的之前处理和之后处理，也就
t可以处理一个网站的所有客户请
|
这种模式主要工作于表
。在这些请求中，有一些请
解释或补充内容，之后才能
和系统响应都需要一定的预
等。通常这些处理的结果都
来表示。
|
示层，负责处理不同类型的请求
求会直接传送给后端模块处理，
传送给后端模块。这种模式的提
处理和后处理，例如用户身份、
会决定用户的请求是否能够进行
|
，同时也需要进行多种不同的处理
而另外一些请求则先会在过滤器里
出主要是由于一个客户的Web访问
用户环境信息、用户请求的合法性
，或是系统的响应应该用什么格式
|
对于这种预处理和后处理问题，传统
就是一整套if/else语句，并且指定如果
显然，这种方法是存在很大弊端的，即代
工作融于一般的程序模块，使得整个程序
|
上，开发人员会设计一系列额外的检测程序模块，也
其中任何一个检测失败，所有的处理工作都会退出。
码的可读性、可维护性都会被大大降低，同时将检测
的模块性难以保证。
|
解决这种问题的关键在于，设计一种
这些模块通常都能够完成一定的检测和过
模式----截取过滤器作为解决方案，这种
入的过滤器来执行一般的处理功能。
|
简单的技术，以能够添加或移除额外处理的模块，而
滤功能。根据以上的讨论，J2EE研究人员提出了设计
模式可以在不影响核心处理模块的情况下，实现可插
|
从理论上来说，这种过
；同时开发人员也可以随时
|
滤器可以截取客户请求和系统响
根据需要移除这些过滤器，并不
|
应，并进行相应的预处理和后处理
用担心会改变任何其他模块。
|
我们这里所说的预处理
统调试等。执行这些功能的
变化，这些模块随时可能被
|
和后处理功能，通常是指一些基
过滤器通常是需要与核心模块分
添加或删除。
|
本的系统服务，如安全、登录，系
开的，并且由于系统职能或规则的
|
下面提供一些关于截取
以运用。图19表示了截取过
之间的联系。
|
过滤器的图示，以帮助大家更好
滤器模式的整体结构，图19显示
|
地理解这种设计模式，并合理地加
了截取过滤器中的参与模块和相互
|
(1)过滤管理器(Filter
器链对象以及相应的过滤器
|
Manager)。过滤管理器负责过
组建，并初始化整个处理过程。
|
滤器的主要处理工作，即创建过滤
|
(2)过滤器链(Filter C
|
hain)。过滤器链是一组互不依
|
赖的过滤器有序集合。
|
(3)过滤器1，过滤器2，过滤器3(Fil
不同服务的过滤器，而过滤器链则负责它
|
terOne，FilterTwo，FilterThree)。这些都是提供
们的协调工作。
|
通过采用这种设计模式
处理多种请求的中心模块，
更好地与处理模块所提供的
并提供相当灵活的服务组合
时根据需要从其他程序模块
使用一组类似的过滤器，并
|
，应用系统可以取得更方便的中
并能根据后端的处理模块而解释
功能匹配。另外，过滤器通常可
，应用系统可以通过使用截取过
中插入或移除，并且由于它们通
在不同的情况下进行全组的重用
|
心控制，这是由于过滤器可以提供
和润色用户的请求，使得该请求能
以将不同种类的服务聚集在一起，
滤器提高其重用性，过滤器可以随
常具有标准的接口，开发人员可以
。
|
采用这种设计模式也会
由于根据其定义和需求，每
需要共享信息的话，其代价
|
带来一定的问题，即在过滤器之
个过滤器的设计和开发都大相径
将是非常昂贵的。
|
间共享信息将变得非常困难，这是
庭。因而如果在不同的过滤器之间
| |
| |
|
|
|
