dorado技术园地

与您共同讨论dorado技术及其应用技巧

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  8 随笔 :: 0 文章 :: 37 评论 :: 1 Trackbacks

要了解dorado的详情请浏览http://www.bstek.com

http://www.blogjava.net/dorado/archive/2005/07/25/8367.html
中我们已经了解到
dorado的开发模式与传统的基于MVC的企业应用开发模式之间存在着一些差异. 可能看到这里您已经产生了一大堆的问题:

l         为什么一定要有这样的差异存在?

l         这种差异将在多大的程度上影响我们企业原有的系统或开发框架(开发规范)?

l         这种差异将在多大的程度上影响程序员原有的编程习惯?

l         Dorado的开发方式是否拥有足够的健壮性、足够的扩展性?

为了深入的解答上述这些问题, 我们首先来了解一下传统的MVC开发模式. 如下图(此处的Control以目前最为流行的Struts为例):

mvc.gif
图表
传统的基于MVC架构开发模式

1.       Request(请求) Client(浏览器)发起请求时, 改请求将首先被控制层(StrutsAction)接受.

2.       Dispatch(分发): Action将调用具体的Model中的BO对象来完成实际的业务逻辑操作, 然后将执行结果存贮于RequestAttributies. (一般惯例是这样的)

3.       Forward(转向): 商业逻辑执行完成后Action将根据商业逻辑的执行结果将Request转向给具体的视图(JSP).

4.       Extract(提取): 一般而言JSP不会去直接访问Model, 而是直接到RequestAttributies中提取已经在第2歩存放好的业务数据.

5.       Response(反馈): 视图的Server端准备工作完成后会自动将各种信息输出到Response对象中反馈给Client.

从上面的分析我们不难看到在这种开发模式中, 业务逻辑主要都是在Action中完成调用的, 然后通过RequestAttributies作为上下文对象在ActionJSP之间传递信息.

那么基于dorado的开发是否也可以按照这种方式来操作呢? 答案是可以, 但是dorado中某些高级功能会受到一些影响.

因为在传统的B/S应用中, ClientServer端的交互完全是通过HTML FORM来完成. 而且每次执行完一个业务逻辑操作之后往往会刷新整个Client页面, 即连同操作结果和HTML一起下载并重新装载整个Client页面. 可是在doradoClient中我们可以实现很多类似页面局部刷新、数据分批下载、远程方法调用、复杂数据对象的整体提交这样的功能. 这些功能的实现不能完全依赖于传统的HTML FORM的提交来完成, 而是需要依靠浏览器的XMLHTTP技术.

提示

上面提到的dorado中的页面局部刷新、数据分批下载、远程方法调用、复杂数据对象的整体提交等功能您可以通过dorado的SampleCenter中的下面一个例子来体验.



综上
, 对于Server端的程序而言传统的B/S应用和dorado应用最大的差别就在于此.

l         在传统的B/S应用中Server端的程序只需要处理一种Client请求, 即执行逻辑然后返回视图, 且要处理的Client请求的参数类型都是类同的.

l         dorado应用中Server端的程序需要处理至少两种Client请求. 其中一种是简单的类似传统B/S应用的请求, 另一种是dorado独具的用于处理类似数据分批下载和复杂数据提交的请求, 这一类请求都是通过XMLHTTP技术提交的, 其参数信息都包含在一段XML. 且这一类请求的反馈结果必须同样是XML格式的, 其中只包含数据和执行结果, 不能包含HTML信息.

这样一来我们便很难将所有的请求的处理代码一概放到Action中完成. 因为对于dorado应用, 其中的部分请求的参数是相对比较复杂的XML. 所以为了避免自己手工的去解析和组装XML, 我们应当把这种请求的业务逻辑调用放到doradoModule或着ViewModel, dorado来帮我们完成繁琐的XML信息处理, 我们只要直接使用通过解析获得的Java对象型的数据就可以了.

那么这种方式是否意味着原本集中在Action中的业务逻辑调用被分散到了几个不同的环节, 造成系统中业务逻辑的分散而不易管理呢? 应该说只要我们对系统稍作调整就可以避免这个问题的出现了 – 我们需要引入业务代表层(BO Delegate).

struts-action.gif
图表
原有的系统调用BO的模式

如上图所示, 在原有的系统中我们一般首先会在Action中将Request中附带的Parameter等信息提供给BO Delegate, BO Delegate将其组装成一个或几个VO(Value Object)对象, 或者直接使用Struts提供的FormBean对象作为VO对象. 然后再利用这些VO对象去调用自己的业务逻辑对象. 对于BO而言, 他的前端介面就是VO.

注意

在您的系统有可能并没有明确的定义BO Delegate这种对象, 可它事实上往往是存在的. 除非您的系统中直接将Request对象传进了BO. 如果是这样的话, 我们认为你的系统原本也属于应进行重构的范畴. 因为这样的BO层与Request进行了不必要的耦合, 大大降低了系统的可扩展性. 且这样的BO是无法支持单元测试(测试驱动开发的).


对于dorado应用而言BO仍可以以完全相同的VO作为其前端介面, 只是我们需要另外一种或几种BO Delegate负责将不同的外部数据构造成统一的VO对象. 

dorado-action.gif
图表
改造后系统调用BO的模式

如上图所示, Action接到XMLHTTP发送的请求时会将处理转交给dorado中的ModuleViewModel对象来处理, 由他们首先来完成对XML提交信息的解析. 而后再利用BO Delegate将这些信息组装成BO所需要的VO对象. 这样, 我们事实上几乎不需要对BO层做什么改动就可以将dorado导入到系统中了. 而且很明显这样的调整是不会影响到整个系统的扩展性的.

从另外一个简单的角度来看这个问题, 事实上就是在新的系统架构中我们保留整个Model层的设计, dorado来替换原先的View. 然后在Model层和doradoView层直接通过一组特别定义的交互接口来实现对接. 对接时使用VO作为数据交换对象. 同时dorado又特别提供了DODatasetDOUtils等对象和工具类可以辅助我们更加方便的构造和溶解各种类型的VO对象. 因此你大可不必为整合dorado而大伤脑筋, 尽管他需要我们适当的调整原有的开发习惯, 但是dorado带给我们的其它好处是显而易见的.

 

posted on 2005-07-19 17:13 dorado技术园地 阅读(2715) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: