问题描述
公司的项目基本上一个domain就对应一个dao接口和一个实现daoImpl,可是我想了好一阵子都没想出这有什么好,我的想法是:domain继承于EntityBase,然后用一个dao,方法是通用增删改查方法和执行原生SQL语句的方法以及调用存储过程的方法等,参数用泛型<T extneds EntityBase>,复杂的业务全部定义在service中,在service中组合dao里面的方法,就不用给每一个domain定义dao实现了,求过来人指点下
解决方案
其实这样设计是为了降低类之间的耦合,你说的 那种抽象出来但是耦合性太大你可以看下jpa的现在设计,他的repository的设计的 就是体现出来了 现在大部分框架都是尽量低耦合的,你看下这个文章:http://www.cnblogs.com/tiwlin/archive/2010/02/24/1672459.html
解决方案二:
你这样的想法也行如果你这想法能满足你的需要就这样干!个人的一个思路: 你可以分4层 action(处理请求)--》service(处理逻辑)--》manger(编写动态sql)——》dao(传入动态sql去执行)
解决方案三:
这样设计是对的,之前的写法图省事简单。
解决方案四:
因为大多数时候所需的sql是不规整的,四五个通用的简单dao的api满足不了需求,不过话说回来如果前人已经封装好了,估计谁都乐意用,没有现成的嘛大部分人就不太愿意在眼前的项目工时中去做这种基础建设咯。
解决方案五:
你这个想法是对的,善于抽象,省了不少复杂的代码,省去了每一个dao都要重复的继承框架的Support实现类(hibernateDaoSupport),我们公司的代码基本上是这么干的。
时间: 2024-09-17 16:29:51