图表 1基于MVC模式的总体框架图

上图是利用dorado的表现层与目前较为流行的Struts、Hibernate、Spring进行协同开发的总体框架图。从此图中我们不难看出与传统的MVC的开发模式的最大区别在于View部分dorado的表现层实现。

1．             发起请求 从浏览器发出请求开始(如图中的1号箭头)。该请求首先将被Struts的ActionServlet接受，然后ActionServlet会根据用户的Struts配置确定应触发哪一个具体的Action。

2．             调用业务逻辑 Action的主要任务是调用某一个业务逻辑对象BO(Business Object)已完成相应的业务操作。由于我们在此框架考虑引入了Spring，因此Action将不必直接创建具体的BO。而是通过Spring框架利用反向注入的原理(Ioc)来得到BO的实例。
在BO当中我们应当通过数据访问对象DAO(Data Access Object)来实现对数据的访问操作。由于我们考虑在开发模式中引入Spring。因此，此处具体使用的DAO实例也应通过Spring来获取。
为了更好地实现业务逻辑的面向对象化，我们还可以考虑利用Hibernate来作为DAO的具体实现方式。如此便有的了上图中所展示的Model层的架构。最终在整个系统中DAO成为了唯一的数据库访问途经。通常我们可以将此图中的DAO和Hibernate统称为数据持久层。
另外，在某些情况我们也可以考虑简化此处的持久层设计。由于Hibernate本身就可以作为独立的持久层实现，因此也可以将此处的DAO对象省去，直接在BO中利用Hibernate完成数据访问。
当我们的Action完成了对BO的调用之后，我们应当将业务逻辑个直接结果存入到上下文对象(Context)当中，以便于稍后的View能够得到这些数据并用于界面的绘制和展现。在通常模式下BO的执行结果都是以VO（Value Object）的方式返回的。VO既可以可以独立的JavaBean也可以是JavaBean的集合(Collection， 例如：List 、Set) 。

3．             转发请求 当Action完成上述操作之后Struts应根据BO的执行结果和用户的配置将请求转发给某个具体的JSP来实现界面的展现。由于此处引入了dorado的表现层，因此JSP的作用已被弱化为了单一的对视图模型(ViewModel)中的各种可视化对象进行布局。
视图模型是一种用户描述视图逻辑的对象。例如我们将表格要如何显示、单击按钮后要完成什么动作、下拉框如何进行赋值等信息都归纳为视图逻辑。视图模型只负责声明和描述对象，而不负责对象具体的摆放位置。视图模型无法独立的访问View层之外的数据，视图模型只能引用在数据模块(Module)中定义的数据。
数据模块是dorado的表现层中专门用于访问外部数据的一种对象。例如在此处的开发模式当中我们就利用数据模块来访问BO返回的执行结果。

4．             值对象(VO)的传递    由于我们不能把数据模块的激活和BO的调用看作是一个同步的过程。因此数据模块无法直接得到BO返回的执行结果，而只能通过上下文对象来获取BO返回的VO。此处的上下文对象一般是指Request对象的Attributies属性集。
数据模块在得到VO之后需要自动将VO中包含的信息反射成dorado中的数据集(Dataset)。由于此种数据转化在某些极端的情况是非常复杂的(例如VO的多级集合嵌套)，因此我们必要定义一些描述信息来辅助dorado按照正确的方式进行数据转换。值得庆幸的是dorado的Studio可以自动生成绝大部分的描述信息。我们只需要根据实际情况的在必要的时候对这些描述信息做少量的调整就可以了。

5．             反馈 VO的信息被正确的转化到Dataset中之后，dorado的Module和ViewModel将按照其标准的方式运行，并最终通过JSP将视图信息反馈给浏览器。此处，dorado的表现层之所以需要数据模块、视图模型和JSP的协同工作是为了更好的实现代码的重用。

综上5个步骤，我们不难看出dorado与Struts、Hibernate、Spring这些产品进行整合的关键在步骤4，即如何将VO转换成dorado中的Dataset。而且事实上dorado的对象本身完全不需要对Struts、Hibernate、Spring中的任何对象进行直接调用。这种松耦合的结合方式可以充分的保证系统架构将来的灵活性和扩展性。

结论

此种开发模式与传统的开发模式比较，其最大的优势在于可以利用dorado大大的节省开发人员在开发Web应用表现层式的工作量，同时又为我们的应用提供非常友好、易用的用户交互界面，将应用直接升级成新一代的富客户端网络应用(Rich Internet Application)。

此种开发模式与标准的dorado的开发相比将会带来开发工作量的明显加大，不过同时在开发模式上的标准化也可以在另外一些方面为我们带来好处。例如可以系统架构具有更好的扩展性，使得将来在需要的时候引入其他框架类产品的变得相对容易。

Dorado除可以帮我们改善界面之外，还可以为我们提供国际化、性能分析、权限配置等等诸多实用的功能，由此可见引入dorado作带来的好处是不言而喻的，此处不做过多累述。但是对于上表中的后两种开发方式的取舍应根据多方面的实际情况来决断。一般而言，对于规模不是特别大，参与开发的人员不多且预计系统将来升级和扩展不是很频繁的项目，我们仍推荐选用相对简单且快速的第三种方式，即直接使用dorado标准的开发模式。

与了解更多详情请浏览一下网址:
http://61.151.239.187/doradosample/hibernate2.show.d
http://61.151.239.187/doradosample/hibernate3.show.d

方法一: 使用标准的JDBC对象完成数据操作.

Dorado提供了一个工具类，com.bstek.dorado.common.TransactionManager，该类提供一个静态方法：

Transaction getTransaction(DoradoContext context) throws java.lang.Exception

获取与指定的上下文(DoradoContext)相关的事务对象.

这样我们得到一个默认的处理事务对象，通过该事务对象提供的方法：

Connection getConnection(java.lang.String dataSource) throws java.lang.Exception

获取一个与本事务相关的Connection，自定义的更新就通过这个Connection对象处理，最后系统会自动管理整个事务。

代码示例: 

Transaction transaction = TransactionManager.getTransaction(context);
Connection connection = transaction.getConnection(null);
try {
    // 利用connection对象进行数据操作.
}
finally {
    connection.close();
}

方法二: 使用标准的dorado的Dataset和DBStatement对象完成数据操作.

除了使用上面的方法之外, 我们还可以使用dorado中提供的Dataset和DBStatement对象完成数据操作. 这种做法优点在于:

1.       可直接集成Context中的当前事务, 代码量小.

2.       支持命名参数, 使用方便.

使用SqlDataset添加记录的代码示例:

AutoSqlDataset dataset = new AutoSqlDataset();
dataset.setOriginTable("employee"); //设置要操作的数据库表名
dataset.setKeyFields("employee_id"); //设置该表的主键(在更新或删除记录时必须设置)    

dataset.insertRecord(); //插入一条空记录
// 以下代码设置新记录的值
dataset.setString("employee_id", "GUOLIWEI");
dataset.setString("employee_name", "国莅伟");
dataset.setBoolean("sex", false);    

dataset.insertRecord(); //插入另一条空记录
// 以下代码设置新记录的值
dataset.setString("employee_id", "PANLONG");
dataset.setString("employee_name", "盘龙");
dataset.setBoolean("sex", true);

dataset.update(context); //将所做的修改更新到数据库中

使用DBStatement对象的代码示例:

DBStatement statement = new DBStatement(
    null, "INSERT INTO LOG (MSG_TIME, MSG) VALUES (:timestamp, :message)");
ParameterSet parameters = statement.parameters();    

//添加一条记录
parameters.setDate("timestamp", new Date());
parameters.setString("message", "XXX XXX XXX");
statement.execute(context);

//添加另一条记录
parameters.setDate("timestamp", new Date());
parameters.setString("message", "YYY YYY YYY");
statement.execute(context);

以下的说明基于利用Dorado的MVC框架的基本开发方式:

1.       Request(请求)： 当Client端(浏览器)发起请求时, 改请求将首先被Dorado的控制层(Mapping)接受.

2.       Dispatch(分发): 控制层会跟据用户的配置决定激活哪一个Action.

3.       Forward(转向): 商业逻辑执行完成后Action将根据商业逻辑的执行结果将Request转向给具体的视图(ViewModel). 具体的转向方式由Action的用户配置信息决定.

4.       Extract(提取): 视图(ViewModel)被激活后会通过其中的Dataset对象到Module中提取业务数据. 同时视图也会根据配置信息自动创建各种可视化的控件用于展现提取到的业务数据.

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

注意

上图中以虚线标出了dorado的MVC架构与传统MVC的不同点. 这种不同主要是由dorado强大的Client带来的. 1.     由于dorado的Client不再以传统的HTML FORM作为与Server交互的途径, 而是以XML替代. XML所能构承载的信息量和复杂度远远高于HTML FORM. 所以在dorado的开发模式中往往不在Action中直接调用业务逻辑, 而是等到ViewModel和Module将这些XML解析成对象后再调用业务逻辑. 2.     dorado的Client中除了有普通的类似FORM提交的操作之外, 还存在着一种数据请求操作. 例如在不刷新页面的情况下下载数据集的分页信息、远程方法调用等. 这种请求与普通的提交的操作的处理方式有着很大的不同, 也同样难以通过Action进行统一的处理. 而且利用dorado的MVC开发方式却可以很好解决这一问题. 以上变化, 经过锐道公司extra和dorado两代产品的数十家不同类型、层次的开发的实践证明是完全可行, 且对系统的扩展性、复用性、安全性完全无害的.

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中的下面一个例子来体验. http://61.151.239.187:8080/doradosample/dataset/custom-update1.jsp 可展示页面局部刷新、远程方法调用 http://61.151.239.187:8080/doradosample/dataset/master-detail2.jsp 、http://61.151.239.187:8080/doradosample/integration/hibernate1.jsp 可展示复杂数据对象的整体提交 http://61.151.239.187:8080/doradosample/dropdown/all-dropdown.jsp 可展示页面局部刷新 http://61.151.239.187:8080/doradosample/tree/dynamic-load-tree1.jsp、http://61.151.239.187:8080/doradosample/pilot/customize-pilot1.jsp  可展示数据分批下载

综上, 对于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带给我们的其它好处是显而易见的.

 

dorado技术园地 2005-07-19 17:13 发表评论

]]>