要了解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架构开发模式
1. Request(请求)： 当Client端(浏览器)发起请求时, 改请求将首先被控制层(Struts的Action)接受.
2. Dispatch(分发): Action将调用具体的Model中的BO对象来完成实际的业务逻辑操作, 然后将执行结果存贮于Request的Attributies中. (一般惯例是这样的)
3. Forward(转向): 商业逻辑执行完成后Action将根据商业逻辑的执行结果将Request转向给具体的视图(JSP).
4. Extract(提取): 一般而言JSP不会去直接访问Model层, 而是直接到Request的Attributies中提取已经在第2歩存放好的业务数据.
5. Response(反馈): 视图的Server端准备工作完成后会自动将各种信息输出到Response对象中反馈给Client端.
从上面的分析我们不难看到在这种开发模式中, 业务逻辑主要都是在Action中完成调用的, 然后通过Request的Attributies作为上下文对象在Action和JSP之间传递信息.
那么基于dorado的开发是否也可以按照这种方式来操作呢? 答案是可以, 但是dorado中某些高级功能会受到一些影响.
因为在传统的B/S应用中, Client与Server端的交互完全是通过HTML FORM来完成. 而且每次执行完一个业务逻辑操作之后往往会刷新整个Client页面, 即连同操作结果和HTML一起下载并重新装载整个Client页面. 可是在dorado的Client中我们可以实现很多类似页面局部刷新、数据分批下载、远程方法调用、复杂数据对象的整体提交这样的功能. 这些功能的实现不能完全依赖于传统的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, 我们应当把这种请求的业务逻辑调用放到dorado的Module或着ViewModel中, 让dorado来帮我们完成繁琐的XML信息处理, 我们只要直接使用通过解析获得的Java对象型的数据就可以了.
那么这种方式是否意味着原本集中在Action中的业务逻辑调用被分散到了几个不同的环节, 造成系统中业务逻辑的分散而不易管理呢? 应该说只要我们对系统稍作调整就可以避免这个问题的出现了 – 我们需要引入业务代表层(BO Delegate).
图表 原有的系统调用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对象.
图表 改造后系统调用BO的模式
如上图所示, 当Action接到XMLHTTP发送的请求时会将处理转交给dorado中的Module或ViewModel对象来处理, 由他们首先来完成对XML提交信息的解析. 而后再利用BO Delegate将这些信息组装成BO所需要的VO对象. 这样, 我们事实上几乎不需要对BO层做什么改动就可以将dorado导入到系统中了. 而且很明显这样的调整是不会影响到整个系统的扩展性的.
从另外一个简单的角度来看这个问题, 事实上就是在新的系统架构中我们保留整个Model层的设计, 用dorado来替换原先的View层. 然后在Model层和dorado的View层直接通过一组特别定义的交互接口来实现对接. 对接时使用VO作为数据交换对象. 同时dorado又特别提供了DODataset和DOUtils等对象和工具类可以辅助我们更加方便的构造和溶解各种类型的VO对象. 因此你大可不必为整合dorado而大伤脑筋, 尽管他需要我们适当的调整原有的开发习惯, 但是dorado带给我们的其它好处是显而易见的.