|
锁定老帖子 主题：DAO的一个讨论问题
精华帖 (1) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (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());
}
|
| 返回顶楼 | |
|
发表时间：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访问代码混一起，那改起来。。。 分层，就是把复杂的事情简单化，有步骤，分层次地去解决实际问题，遇到错误也好定位，代码 也容易测试。 |
| 返回顶楼 | |
|
发表时间：2008-07-25
"为什么整个项目都写在一个文件里呢"
那会发生什么呢 维护、权限控制、业务变化 等等 又怎么办呢。 |
| 返回顶楼 | |
|
发表时间：2008-07-25
有人说过，使用JAVA解决某问题如果觉得所设计的框架/代码太复杂时，解决办法就是“加入更多的层次和更多的类”。
关键是看是不是适合自己做的系统了。如果你的应用中不止有关系数据库做为dao，还有xml文件和webservice接口等做为dao，那么它确实是必不可少的。 |
| 返回顶楼 | |
|
发表时间：2008-07-25
考虑问题简单了点。做系统要考虑的是可扩展，controller->dao 。。把复杂的业务也写到dao了？到时候，如果添加功能需要aop 你怎么办。。。估计还要把 controller里的 dao 抽出来个service层了 。对service进行AOP。。。根据你的业务状况仔细想想吧。。
|
| 返回顶楼 | |
|
发表时间：2008-07-25
最近的项目设计中，淡化dao层设计，dao层用泛型实现就可以了， 所有的实现都集中在业务层中，而且事务的提交也都是定义在Service层中。
|
| 返回顶楼 | |
|
发表时间：2008-07-25
laiseeme 写道 一直用一个basedao 不过用的是hibernate，一个通用的dao里面包括了一些基本的查询，添加修改删除等等，各个模块dao继承这个basedao，有这个模块相对个性的查询就写到这里面，通用的查询等等就调用basedao里面的方法
我记得Eclipse有个Hibernate的插件，就提供BaseDAO这样风格的代码的自动生成~~以前某个项目中用过 |
| 返回顶楼 | |
|
发表时间：2008-07-26
现在的spring或者mvc董事采用的三层模式，action--manager---dao
每个层次之间都有明显的分工 action是用来处理参数，调用对应的业务逻辑，控制页面跳转方向， manager则是编写业务逻辑的层次，所谓的业务逻辑就是把对数据库的单元操作组装起来，并作数据的逻辑处理，简化就是说 每个方法要做一件事情 dao则是对数据库的单元操作，每个方法都是对数据库的一个基本操作。 楼主说的数据表结构变动的问题，我觉得如果严格按照这个层次来分的话，并且接口设计的合理的话，应该不需要频繁的变动的，如果数据库表结构变动的话，可能只需要变动的是action中获取参数的时候，还有dao的对应方法 |
| 返回顶楼 | |
|
发表时间：2008-07-27
Action<-Service<-Dao<-DB
贴段代码，可能就比较清楚了
service Interface:
public interface SpaScoreDAOService {
public List getSpaScoreSupInfo(String supItems);
....
}
DAO:(IBatis)
public class SpaScoreDAO extends SqlMapClientDaoSupport {
public List getSpaScoreSupInfo(String supItems) {
return this.getSqlMapClientTemplate().queryForList("getSpaScoreSupInfo",supItems);
}
Service implement:
public class SpaScoreDAOImp implements SpaScoreDAOService {
SpaScoreDAO spaScoreDAO;
public List getSpaScoreSupInfo(String supItems) {
...业务逻辑
return spaScoreDAO.getSpaScoreSupInfo(supItems);
}
public SpaScoreDAO getSpaScoreDAO() {
return spaScoreDAO;
}
public void setSpaScoreDAO(SpaScoreDAO paScoreDAO){
this.spaScoreDAO = spaScoreDAO;
}
Action:
public class SpaScoreAction extends Action{
private SpaScoreDAOService spaScoreDAOService;
public ActionForward execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) {
//调用业务逻辑
List supitemList = spaScoreDAOService.getSpaScoreSupInf(supItems);
......
}
public SpaScoreDAOService getSpaScoreDAOService() {
return spaScoreDAOService;
}
public void setSpaScoreDAOService(SpaScoreDAOService spaScoreDAOService) {
this.spaScoreDAOService = spaScoreDAOService;
}
|
| 返回顶楼 | |
|
发表时间：2008-07-30
搂主的想法是对的，其实就是应该在设置一个业务逻辑层
比如Jsp->Action->Bussiness->Dao->PO 这样还不能满足楼主的要求吗?建一个业务逻辑层,完成对所有持久化类的访问.不就所说的"一个整合DAO". |
| 返回顶楼 | |
