开源技术Struts、Spring、Hibernate(9)

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

图4.9 与article POJO对应的对象关系映射文件article.hbm.xml

图4.10 与article.hbm.xml对应的表

如上面三个图说展示的，POJO的每一个属性都通过其映射文件把规则映射到表中的字段，通过这样一种设计，这样只要对对象进行操作，也就同样对表进行了操作。

2 数据持久层设计

复杂性是应用开发过程中最令人头疼的一个问题。每当在一个应用中增加一个功能时，它的复杂性通常呈次方级的增长[23]。这种复杂性往往导致程序的开发无法再继续下去。这也是现在为什么许多应用只有Beta版本而没有正式版的原因。

专家将应用开发过程产生的复杂性分为两类，即非本质的（accidental）和本质的（essential）。本质的复杂性是对于解决目标问题所必然产生的复杂性，非本质的复杂性是由于选择了不适当的开发工具和设计工具而产生的复杂性。对于一个功能确定的程序来讲，本质的复杂性是确定的，而非本质的复杂性则是没有限制的。因此，一个应用的开发要想较顺利地取得成功，就需要尽可能地减少非本质的复杂性[24]。

设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式，也会使新系统开发者更加容易理解其设计思路。

衡量一个系统优秀与否的关键因素，除了能够满足用户需求外还有如下方面：首先是灵活性。灵活性意指这种结构或模式不依赖于任何实际应用，应该与操作系统、应用程序无关。提供独立的结构，可以提供最大的重用。其次是可扩展性。随着业务的扩展，新的业务不断增加，业务逻辑自然增加，系统必然会进行修改或添加相应功能模块。再次是可配置性。最后是安全性。

数据持久层的设计采纳了多种设计模式，最大限度的降低了系统内部各模块、子系统间的耦合性，使得系统相对易于扩展，并且能够在进行改变时，保证持久层的业务逻辑层相对稳定，基本不需要因持久层的调整改变而进行逻辑层的变动。

3 数据访问对象（DAO）

根据数据源不同，数据访问也不同。根据存储的类型(关系数据库、面向对象数据库等)和供应商不同，持久性存储(比如数据库)的访问差别也很大。当业务组件或表示组件需要访问某数据源时，它们可以使用合适的API来获得连接性，以及操作该数据源。但是在这些组件中包含连接性和数据访问代码会引入这些组件及数据源实现之间的紧密耦合。组件中这类代码依赖性使应用程序从某种数据源迁移到其

-40-

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

它种类的数据源将变得非常麻烦和困难，当数据源变化时，组件也需要改变，以便于能够处理新类型的数据源。

在本项目开发项中，数据持久层使用数据访问对象(DAO)来抽象和封装所有对数据源的访问。DAO管理着与数据源的连接以便于检索和存储数据，DAO实现了用来操作数据源的访问机制，内部封装了对Hibenernate数据操纵、事务处理、会话管理等API的封装。外界依赖于DAO的业务组件为其客户端使用DAO提供了更简单的接口，DAO完全向客户端隐藏了数据源实现细节。由于当低层数据源实现变化时，DAO向客户端提供的接口不会变化，采用该设计模式允许DAO调整到不同的存储方式，而不会影响其客户端或业务组件，即使将来不再采用Hibernate作为关系映射框架，上层客户端也不会受到任何影响。另外，DAO还充当组件和数据源之间的适配器的角色。由于整个项目持久层的这种设计较多，而且每个模块原理类似，我们仅对资源模块的一个持久层设计方案进行介绍（pictureModule）。如下图4.11所示。每一个DAO都继承对应的接口（本例operateInterface）,这样可以界定对应操作，其实现者pictureDAO实现operatorInterface同时继承Spring框架下HibernateDaoSupport对象，这样即在规范下操作，又获得了Spring框架中DAO的支持，运行结果可以得到相关对象（picture）。

<<实现类>>pictureDAO+save()()+findByID() : object(idl)+delete()()+merge(Picture detachedInstance)() : object(idl)+findAllForRecycle()() : any(idl)+findAll()() : any(idl)+findByPictureDisplayPlace(Object pictureDisplayPlace)() : any(idl)+findByPictureContent(Object pictureContent)() : object(idl)+findByPictureUrl(Object pictureUrl)() : object(idl)+findByPictureName(Object pictureName)() : any(idl)+findByProperty(String propertyName, Object value)() : object(idl)+findById( java.lang.String id)() : object(idl)picture-id : any(idl)-name : string(idl)-url : string(idl)-content : string(idl)-isDelete : char(idl)-deleteTime : octet(idl)-pictureCreateTime : string(idl)<<接口>>operateInterface+save()()+findById()() : object(idl)+findByTitle()() : object(idl)+delete()()+findByproperty(object tem,object tem2)() : object(idl)+finBypictureName(String name)() : object(idl)+findBypictureUrl(String url)() : object(idl)+findByPictureDisplayPlace(Object pictureDisplayPlace)() : object(idl)+findAll()() : any(idl)+findAllForRecycle()() : any(idl)+merge(Picture detachedInstance)()+.....()

图4.11 图片（picture）模块设计

4.4.2业务层设计

与为什么需要数据访问层类似，如果我们曾经进行过缺乏业务层的应用构建，那么对于这个问题的回答就相当简单直白了。如果我们不把所有的业务逻辑都集中在一个独立的区域，那么最后的结果就是逻辑代码散布在表现层代码之间，典型的结果就是大量的代码重复，更不要提创建缺乏明确职责边界的代码。撇开代码重复问题，缺乏明确职责界定的代码通常难于维护，因为很难知道某个功能实现到底位于何处。

一个定义明晰的业务层扮演着应用程序入口的角色，为我们的表现层代码提供了一个简单统一的业

-41-

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

务逻辑实现点。好的业务层也对我们的应用在执行何种操作，以及向用户表达怎样的逻辑进行了明确的定义。

如果我们决定采用两种不同类型的用户界面对同一逻辑进行表述，那么忽略逻辑层的一个重大缺陷将浮出水面。例如我们提供了一个Web应用，同时，我们又计划为经常使用这项应用的客户提供一个桌面客户端软件，如果逻辑代码与Web表现层代码相混合，那么我们就不得不进行代码重构，或者干脆针对Swing或者SWT重新编写一份新的逻辑实现，这需要大量的重复开发和测试工作。对构建一个稳固的业务层的重要性进行强调永远都不会显得多余。如果没有业务层，就很可能会导致我们的项目失败。无法通过集中化的方式进行业务逻辑处理，不可避免的将导致更多的错误，维护工作的噩梦以及不愉快的客户体验。

在业务层设计中，为实现表现层和业务逻辑层之间的最大限度解耦，引入了业务代理模式 (buiness proxy)，这样，当表现层或业务逻辑层具体实现发生变化时，对彼此的影响很小。使用业务代理模式的好处是:

1.业务层所有服务完全展示给客户端，客户端可以完全介入调用。 2 动态扩展性强，可 …… 此处隐藏：5446字，全部文档内容请下载后查看。喜欢就下载吧 ……