持久层设计方案比较

一个软件项目，少不了数据的持久化，那么，怎么设计才能让系统代码具有更好的可维护性，让程序员更高效地进行核心业务的开发呢？下面是笔者在一些项目中使用过的持久层设计方案。
我们现在假设要写一个在线书店项目，用户要登录系统，并对图书进行管理，我们可以看到下面的几种持久层设计方案在这个项目中的优劣。
（如果图片看不清，请点右键，查看图片，原图是高清晰的哈）

方案一：

设计图中有些方法笔者进行了简化，本文的重点在于方案比较。上面的这种设计方案应该是非普通的一种做法，它有如下的一些优点：
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实现类，这 样，每个实体持久化类就有了全部的通用化持久层方法，如果你的实体持久化需要什么特殊的持久化方法，只需添加这些特殊的持久化方法（一般是查询方法）即 可，非常的方便。
有不同设计方案的同学，可以与我沟通。

本文首发http://www.fudu365.com【英语听力复读网】，转载请保留。