欢迎来到HugNew-拥抱变化,扫一扫右边二维码关注微信订阅号:Martin说 或 加QQ群:427697041互相交流,Stay hungry, Stay foolish.

四种持久层设计方案比较

J2EE Martin 2160℃ 0评论

一个软件项目,少不了数据的持久化,那么,怎么设计才能让系统代码具有更好的可维护性,让程序员更高效地进行核心业务的开发呢?下面是笔者在一些项目中使用过的持久层设计方案。

我们现在假设要写一个在线书店项目,用户要登录系统,并对图书进行管理,我们可以看到下面的几种持久层设计方案在这个项目中的优劣。

方案一:

持久层设计方案一

持久层设计方案一

设计图中有些方法笔者进行了简化,本文的重点在于方案比较。上面的这种设计方案应该是非普通的一种做法,它有如下的一些优点:

1、业务层只负责实现业务,与持久层相关的所有东西(sql、hql等),全部放到dao实现类中去做。

2、方便数据库性能优化,所有数据库职责以按实体对象为粒度进行分配,所有的sql指令均由dao这里发出。

3、结构清晰,dao就是ddd中的仓储对象。

缺点:

不利于系统后期维护。后期一但要加功能,工作量比较大,首先你得加业务层的方法,很有可能也要为实体dao添加方法,这样一来,一处业务修改,就会动到dao接口及期实现类,加上业务层接口、实现类,修改达4处,对于新手来说,很容易迷糊。

方案二:

持久层设计方案二

方案二采用通用dao,实现所有的CRUD操作,在业务实现类中注入通用dao完成业务对持久层的操作,该方案的优点是简单,添加业务实现类或修改业务实现 类时,非常的方便,一个地方搞定;当然,很多好的东西都是双刃剑,该方案必然会在业务实现代码中出现sql、hql等持久层与数据库相关的逻辑,很多人认 为这种做法不OO,职责划分不分明。但是这种方案在项目中也是很有用的,谁说sql就一定是数据库的东西,多年前我可是擅长用存储过程来实现业务 哈,sql本身就和业务密不可分哦。

方案三:

持久层设计方案三

方案三也采用的是通用Dao实现。该方案根据OOD的开闭原则,将持久层中的增、删、改三种不变化的操作封装到CRU_DAO中,而将查询封装到 IFinder中,实现类中封装的也是通用持久化方法。但这种设计中,要求业务接口必须继承通用接口,业务实现类也要继承通用实现dao实现以获得持久化能力。

该方案的优点是让程序员感觉只有业务层的存在,似乎更加容易理解,但该框架让业务实现类通过继承获得持久化功能,违背了“组合聚合优于继承”的设计原则。

我用这种方案做过一些项目,感觉不是太方便,但中国移动的大部分系统都是用这种持久层设计方案实现的,用得倒也挺好的。

方案四:

持久层设计方案四

这种方案是我在HP中国的一些项目中看到的,自己也曾在多个项目中实践,应该是一种非常不错的设计方案,虽然在图上看起来有些杂乱,但该方案确实能大幅提升开发效率。

该方案中,有通用的dao接口,所有crud与通用分页的方法都加入通用dao接口中,该接口有一个具体的实现。在业务层与持久层的设计上,我们还是采用方 案1的做法,相关实体都有自己的持久化接口,但实体的持久化接口都从通用dao接口继承,持久化实现类在实现自有接口的同时,继承通用dao实现类,这 样,每个实体持久化类就有了全部的通用化持久层方法,如果你的实体持久化需要什么特殊的持久化方法,只需添加这些特殊的持久化方法(一般是查询方法)即可,非常的方便。接口的同时,继承通用dao实现类,这 样,每个实体持久化类就有了全部的通用化持久层方法,如果你的实体持久化需要什么特殊的持久化方法,只需添加这些特殊的持久化方法(一般是查询方法)即可,非常的方便。

来源:刘江华的博客

转载请注明:HugNew » 四种持久层设计方案比较

喜欢 (2)or分享 (0)
发表我的评论
取消评论

表情