论坛首页 Java版 DAO

DAO的一个讨论问题

浏览 6114 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (5) :: 隐藏帖 (0)
作者 正文
时间:2008-07-21
laiseeme 写道
效率问题大家遇到了么 通常这个dao交给spring容器管理 他市一个单例,大家争用的时候不晓得会不会产生性能问题


可以使用ThreadLocal方式,就算是注入的,也是每个thread一个session,不会有没什么大问题。
   
0 请登录后投票
时间:2008-07-21
写DAO无非是让其对数据库进行操作,如果你想让DAO负责更多的事务,反而失去了他原有的简单而又实用的效果,程序嘛还是自己编的舒心,别人用着放心就好。
   
0 请登录后投票
时间:2008-07-22
是一上不错的想法,不过实现可能会在问题,分层就不明显了
   
0 请登录后投票
时间: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());
	}
   
0 请登录后投票
时间: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访问代码混一起,那改起来。。。
分层,就是把复杂的事情简单化,有步骤,分层次地去解决实际问题,遇到错误也好定位,代码
也容易测试。
   
0 请登录后投票
时间:2008-07-25
"为什么整个项目都写在一个文件里呢"

那会发生什么呢

维护、权限控制、业务变化 等等 又怎么办呢。
   
0 请登录后投票
时间:2008-07-25
有人说过,使用JAVA解决某问题如果觉得所设计的框架/代码太复杂时,解决办法就是“加入更多的层次和更多的类”。
关键是看是不是适合自己做的系统了。如果你的应用中不止有关系数据库做为dao,还有xml文件和webservice接口等做为dao,那么它确实是必不可少的。
   
0 请登录后投票
时间:2008-07-25
考虑问题简单了点。做系统要考虑的是可扩展,controller->dao 。。把复杂的业务也写到dao了?到时候,如果添加功能需要aop 你怎么办。。。估计还要把 controller里的 dao 抽出来个service层了 。对service进行AOP。。。根据你的业务状况仔细想想吧。。
   
0 请登录后投票
时间:2008-07-25
最近的项目设计中,淡化dao层设计,dao层用泛型实现就可以了, 所有的实现都集中在业务层中,而且事务的提交也都是定义在Service层中。
   
0 请登录后投票
时间:2008-07-25
laiseeme 写道
一直用一个basedao 不过用的是hibernate,一个通用的dao里面包括了一些基本的查询,添加修改删除等等,各个模块dao继承这个basedao,有这个模块相对个性的查询就写到这里面,通用的查询等等就调用basedao里面的方法


我记得Eclipse有个Hibernate的插件,就提供BaseDAO这样风格的代码的自动生成~~以前某个项目中用过
   
0 请登录后投票
论坛首页 Java版 DAO

跳转论坛:
JavaEye推荐