Dorado与Struts、Hibernate、Spring的集成开发模式
Dorado与Struts、Hibernate、Spring的集成开发模式
图表 1基于MVC模式的总体框架图
上图是利用dorado的表现层与目前较为流行的Struts、Hibernate、Spring进行协同开发的总体框架图。从此图中我们不难看出与传统的MVC的开发模式的最大区别在于View部分dorado的表现层实现。
发起请求
从浏览器发出请求开始(如图中的1号箭头)。该请求首先将被Struts的ActionServlet接受，然后ActionServlet会根据用户的Struts配置确定应触发哪一个具体的Action。
调用业务逻辑
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) 。
转发请求
当Action完成上述操作之后Struts应根据BO的执行结果和用户的配置将请求转发给某个具体的JSP来实现界面的展现。由于此处引入了dorado的表现层，因此JSP的作用已被弱化为了单一的对视图模型(ViewModel)中的各种可视化对象进行布局。
视图模型是一种用户描述视图逻辑的对象。例如我们将表格要如何显示、单击按钮后要完成什么动作、下拉框如何进行赋值等信息都归纳为视图逻辑。视图模型只负责声明和描述对象，而不负责对象具体的摆放位置。视图模型无法独立的访问View层之外的数据，视图模型只能引用在数据模块(Module)中定义的数据。
数据模块是dorado的表现层中专门用于访问外部数据的一种对象。例如在此处的开发模式当中我们就利用数据模块来访问BO返回的执行结果。
值对象(VO)的传递
由于我们不能把数据模块的激活和BO的调用看作是一个同步的过程。因此数据模块无法直接得到BO返回的执行结果，而只能通过上下文对象来获取BO返回的VO。此处的上下文对象一般是指Request对象的Attributies属性集。
数据模块在得到VO之后需要自动将VO中包含的信息反射成dorado中的数据集(Dataset)。由于此种数据转化在某些极端的情况是非常复杂的(例如VO的多级集合嵌套)，因此我们必要定义一些描述信息来辅助dorado按照正确的方式进行数据转换。值得庆幸的是dorado的Studio可以自动生成绝大部分的描述信息。我们只需要根据实际情况的在必要的时候对这些描述信息做少量的调整就可以了。
反馈 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)。
|
|
工作量 |
界面 |
扩展性 |
| 传统MVC （使用上述开发模式中除dorado外的所有技术） |
最大 |
简陋 |
好 |
| 引入dorado的MVC架构（使用本文介绍的开发模式） |
较大 |
友好(富客户端) |
好 |
| dorado的标准开发模式（不包含Struts、Hibernate、Spring） |
较小 |
友好(富客户端) |
较好 |
Dorado除可以帮我们改善界面之外，还可以为我们提供国际化、性能分析、权限配置等等诸多实用的功能，由此可见引入dorado作带来的好处是不言而喻的，此处不做过多累述。但是对于上表中的后两种开发方式的取舍应根据多方面的实际情况来决断。一般而言，对于规模不是特别大，参与开发的人员不多且预计系统将来升级和扩展不是很频繁的项目，我们仍推荐选用相对简单且快速的第三种方式，即直接使用dorado标准的开发模式。
注：本文引自某人Blog，主要是为了自己学习而收藏的资料