DAO的一个讨论问题

总结：今天在对Action的业务类的方法实现时候，想了又想，为什么在一个Action里面写那么多实现方法对数据库的操作（select，update.....）而且每一个Action都要对应一个DAO的实现方法，每一个DAO的实现方法对对应的数据库的中唯一的一张表，为何不可把Action的对数据库的操作方法写在一个整合的DAO里面呢，在这个整合的DAO里面有的Action对数据库操作的各类的方法，而Action就做全面的数据的转发和JSP页面的跳转工作，当每次对JSP页面操作的时候，（select，update等）都会向整合的DAO执行操作，这个整合的DAO通过产生临时的ID字段负责的全程的对数据库的操作<select，update等>,整合的DAO进行逻辑的判断，进行相关的业务操作，在向不同的DAO的转发，然后在通过不同的DAO对映的数据库表进行操作。请问有人想个这个方法么，就是多张表，每一张表对应的一个DAO的实现类，在通过一个整合DAO实现方法对每个DAO的实现方法的整合，也就是1：n的关系（dao对多个dao的整合）通过整合dao的进行判断执行相关的操作，假如是表关联的话，通过临时字段的ID号判断，要进行那个DAO的操作（表），这样从而减少了Action里面有很多的业务实现方法，对数据库而言，就只有一次性的操作。从而大大的提高数据库的性能效率，有人这样做过么·？ 请那个大人物指点下！谢谢

评论

41 楼 ladofwind 2008-07-24  

soleghost 写道

wm920 写道

总结：今天在对Action的业务类的方法实现时候，想了又想，为什么在一个Action里面写那么多实现方法对数据库的操作（select，update.....）而且每一个Action都要对应一个DAO的实现方法，每一个DAO的实现方法对对应的数据库的中唯一的一张表，为何不可把Action的对数据库的操作方法写在一个整合的DAO里面呢，在这个整合的DAO里面有的Action对数据库操作的各类的方法，而Action就做全面的数据的转发和JSP页面的跳转工作，当每次对JSP页面操作的时候，（select，update等）都会向整合的DAO执行操作，这个整合的DAO通过产生临时的ID字段负责的全程的对数据库的操作<select，update等>,整合的DAO进行逻辑的判断，进行相关的业务操作，在向不同的DAO的转发，然后在通过不同的DAO对映的数据库表进行操作。请问有人想个这个方法么，就是多张表，每一张表对应的一个DAO的实现类，在通过一个整合DAO实现方法对每个DAO的实现方法的整合，也就是1：n的关系（dao对多个dao的整合）通过整合dao的进行判断执行相关的操作，假如是表关联的话，通过临时字段的ID号判断，要进行那个DAO的操作（表），这样从而减少了Action里面有很多的业务实现方法，对数据库而言，就只有一次性的操作。从而大大的提高数据库的性能效率，有人这样做过么·？ 请那个大人物指点下！谢谢

对于业务实体entity，可以只写一个公共的dao，负责每个业务实体entity的CRUD，这样就避免了为每个entity写一个dao及其实现的繁琐
比如

	public <T extends Model> T store(T model) {
		this.getHibernateTemplate().saveOrUpdate(model);
		return (T) this.load(model.getClass(),model.getId());
	}

看来楼主的系统业务不够复杂，如果特别复杂了，逻辑和database访问代码混一起，那改起来。。。
分层，就是把复杂的事情简单化，有步骤，分层次地去解决实际问题，遇到错误也好定位，代码
也容易测试。

40 楼 soleghost 2008-07-22  

wm920 写道

总结：今天在对Action的业务类的方法实现时候，想了又想，为什么在一个Action里面写那么多实现方法对数据库的操作（select，update.....）而且每一个Action都要对应一个DAO的实现方法，每一个DAO的实现方法对对应的数据库的中唯一的一张表，为何不可把Action的对数据库的操作方法写在一个整合的DAO里面呢，在这个整合的DAO里面有的Action对数据库操作的各类的方法，而Action就做全面的数据的转发和JSP页面的跳转工作，当每次对JSP页面操作的时候，（select，update等）都会向整合的DAO执行操作，这个整合的DAO通过产生临时的ID字段负责的全程的对数据库的操作<select，update等>,整合的DAO进行逻辑的判断，进行相关的业务操作，在向不同的DAO的转发，然后在通过不同的DAO对映的数据库表进行操作。请问有人想个这个方法么，就是多张表，每一张表对应的一个DAO的实现类，在通过一个整合DAO实现方法对每个DAO的实现方法的整合，也就是1：n的关系（dao对多个dao的整合）通过整合dao的进行判断执行相关的操作，假如是表关联的话，通过临时字段的ID号判断，要进行那个DAO的操作（表），这样从而减少了Action里面有很多的业务实现方法，对数据库而言，就只有一次性的操作。从而大大的提高数据库的性能效率，有人这样做过么·？ 请那个大人物指点下！谢谢

对于业务实体entity，可以只写一个公共的dao，负责每个业务实体entity的CRUD，这样就避免了为每个entity写一个dao及其实现的繁琐
比如

	public <T extends Model> T store(T model) {
		this.getHibernateTemplate().saveOrUpdate(model);
		return (T) this.load(model.getClass(),model.getId());
	}

39 楼 lkjust08 2008-07-22  

是一上不错的想法，不过实现可能会在问题，分层就不明显了

38 楼 dongbi286 2008-07-21  

写DAO无非是让其对数据库进行操作，如果你想让DAO负责更多的事务，反而失去了他原有的简单而又实用的效果，程序嘛还是自己编的舒心，别人用着放心就好。

37 楼 soartju 2008-07-21  

laiseeme 写道

效率问题大家遇到了么 通常这个dao交给spring容器管理  他市一个单例,大家争用的时候不晓得会不会产生性能问题

可以使用ThreadLocal方式，就算是注入的，也是每个thread一个session，不会有没什么大问题。

36 楼 soartju 2008-07-21  

wm920 写道

总结：今天在对Action的业务类的方法实现时候，想了又想，为什么在一个Action里面写那么多实现方法对数据库的操作（select，update.....）而且每一个Action都要对应一个DAO的实现方法，每一个DAO的实现方法对对应的数据库的中唯一的一张表，为何不可把Action的对数据库的操作方法写在一个整合的DAO里面呢，在这个整合的DAO里面有的Action对数据库操作的各类的方法，而Action就做全面的数据的转发和JSP页面的跳转工作，当每次对JSP页面操作的时候，（select，update等）都会向整合的DAO执行操作，这个整合的DAO通过产生临时的ID字段负责的全程的对数据库的操作<select，update等>,整合的DAO进行逻辑的判断，进行相关的业务操作，在向不同的DAO的转发，然后在通过不同的DAO对映的数据库表进行操作。请问有人想个这个方法么，就是多张表，每一张表对应的一个DAO的实现类，在通过一个整合DAO实现方法对每个DAO的实现方法的整合，也就是1：n的关系（dao对多个dao的整合）通过整合dao的进行判断执行相关的操作，假如是表关联的话，通过临时字段的ID号判断，要进行那个DAO的操作（表），这样从而减少了Action里面有很多的业务实现方法，对数据库而言，就只有一次性的操作。从而大大的提高数据库的性能效率，有人这样做过么·？ 请那个大人物指点下！谢谢

楼主说的整合的那个dao，其实就是service层的，也就是业务层，业务层再调用底层的dao实现。在dao中，仅写crud的东西，尽量与具体的业务无关，而在业务层，写具体的业务逻辑判断，构造数据啥的。action里边直接调用service。

35 楼 wm920 2008-07-21  

wx1985113 写道

action和dao之间加一个service层，在这个层中调用一个业务所需要用到的所有dao方法，再在action中直接调用这个service，可以吧，好像都是这么做的

你的想法在早期的EJB观点里面就出先过了，就拿加载权限模块列表，就是一个典型的列子，

34 楼 csevan 2008-07-21  

面向接口编程～
如果不能抽象成为接口就抽象成抽象类，如果还不行，那么至少传入的东西也放成对象。总之我们是面向对象编程。
加入一个add方法传入的是（id, name）那么你应该写成xx对象，里面有两个属性是ID，NAME 然后public void add(xxObject obj）这样即使你传入参数有变化的话，你也只要修改OBJ了。

33 楼 dobetter 2008-07-20  

不是有DispatchAction吗？

DAO独立于Web程序，即它不知道谁调用它，无论是应用程序还是Web程序。这样程序结构更易修改

32 楼 idaman 2008-07-20  

rihoonet 写道

DAO模式，我觉得太难用了，表结构一改，好多的地方都要改。

   如果是开发期 ， 还会需要需求变更导致修改的地方更多 ， 如果是维护 ， 难道会维护到表结构 ？

laiseeme 写道

效率问题大家遇到了么 通常这个dao交给spring容器管理  他市一个单例,大家争用的时候不晓得会不会产生性能问题

  spring 可以不单例的

31 楼 wx1985113 2008-07-20  

action和dao之间加一个service层，在这个层中调用一个业务所需要用到的所有dao方法，再在action中直接调用这个service，可以吧，好像都是这么做的

30 楼 williamy 2008-07-20  

Joo 写道

范型DAO坛子上不少人都给出源代码过，搜一下吧
但是不知道在持久操作量比较高的情况下，大量利用范型DAO的反射功能会不会存在性能问题。而一般DAO那样的EntityDAO的方法利用多态的运行时动态决定类型貌似要更好一点

1，何来反射
2，action 1：1 dao？ 如此奇妙之设计，何必dao？

29 楼 hifun 2008-07-19  

考虑下
service

28 楼 laiseeme 2008-07-19  

johnnylzb 写道

laiseeme 写道

一直用一个basedao  不过用的是hibernate，一个通用的dao里面包括了一些基本的查询，添加修改删除等等，各个模块dao继承这个basedao，有这个模块相对个性的查询就写到这里面，通用的查询等等就调用basedao里面的方法

这种做法很好，我一向也是这样用，同时把BaseDAO设计成支持泛型，就更加通用和严谨。当然BaseDAO要是接口，把实现屏蔽起来。

对  BaseDAO中接口方法,比如addDomain,removeDomain等等  响应的实现类  比如  针对不同数据库可以实现成MysqlBaseDAO,OracleBaseDAO等等 举个例子  当然用hibernate,如果没有native query 数据库可以随意迁移的

27 楼 laiseeme 2008-07-19  

效率问题大家遇到了么 通常这个dao交给spring容器管理  他市一个单例,大家争用的时候不晓得会不会产生性能问题

26 楼 wm920 2008-07-19  

rihoonet 写道

DAO模式，我觉得太难用了，表结构一改，好多的地方都要改。

从个人的角度上来看，假如按照软件的结构化分层模式开发，会给系统带来效率的问题，也就是说用DAO来进行分层模式开发!

25 楼 wm920 2008-07-19  

williamou 写道

spyker 写道

为什么把数据库的操作写道action中呢
建议创建逻辑层
在逻辑层中对数据进行操作
action调用逻辑层

这是常用的做法。。
但对于一个简单的系统，或者需要快速开发的项目，逻辑层合并在Action里也未尝不可。。

不太理解楼主的问题。。“整合DAO”。。是指一个DAO包含了对多个表操作的方法？这样当然可以阿，但这个类会不会很大呢？
一种对象 -> 一个表 -> 起码CRUD四个方法
5个表就20个方法了。。

action->service-->整合DAO(通过ID来分派到到底是那个表在执行操作，然后直达那个dao)-->一个DAO<表>--->database

24 楼 williamou 2008-07-19  

spyker 写道

为什么把数据库的操作写道action中呢
建议创建逻辑层
在逻辑层中对数据进行操作
action调用逻辑层

这是常用的做法。。
但对于一个简单的系统，或者需要快速开发的项目，逻辑层合并在Action里也未尝不可。。

不太理解楼主的问题。。“整合DAO”。。是指一个DAO包含了对多个表操作的方法？这样当然可以阿，但这个类会不会很大呢？
一种对象 -> 一个表 -> 起码CRUD四个方法
5个表就20个方法了。。

23 楼 disorder 2008-07-19  

rihoonet 写道

DAO模式，我觉得太难用了，表结构一改，好多的地方都要改。

如果是每个表有一个对应的DAO，那么就不会出现这种情况了吧？

22 楼 Acaleph 2008-07-19  

rihoonet 写道

加一个字段、或给字段重命名，是不是DAO里面的接口申明和和实现方法全部都要改？

好的ＤＡＯ设计，修改ＢＥＡＮ就可以完成任务了呵。