当前位置: 代码迷 >> J2EE >> 关于DAO设计方式的疑问,事务该放在业务层处理还是DAO层
  详细解决方案

关于DAO设计方式的疑问,事务该放在业务层处理还是DAO层

热度:134   发布时间:2016-04-21 22:11:33.0
关于DAO设计模式的疑问,事务该放在业务层处理还是DAO层
我现在在学校安排的一家公司实习兼培训,今天和公司教我们的工程师讨论了一下DAO设计模式,关于事务处理该放在哪个层,公司的工程师说事务处理是放在DAO层的方法中,我认为事务应该放在业务层,当然我没有开发经验,但是我觉得在DAO层处理事务的话有些不合理,我觉得DAO层只是实现对于表的最基本的增删改查,而业务就是对数据库的一系列增删改查,在业务层通过调用DAO层的方法来完成相应的业务功能,比如转账,转出账户的余额需要减去转出的钱,转入账户的余额需要加上转入的钱,下面的代码可能不严谨,但仅仅是做为例子来讲解我的意思

/**
*实体类
*/
public class Account{
private Integer userId;//用户ID
private Double Balance;//账户余额
....//get set方法
}
/**
*DAO接口
*/
public Interface AccountDAO{
public boolean update(Account a);
}
/**
*实现类
*/
public class AccountDAOImpl implements AccountDAO{
public void update(Account a){
   //HibernateSessionFactory是myeclipse自动生成的一个获取Hibernate Session的类,
   //它将session保存在一个静态ThreadLocal变量中,这这样对于每个线程,DAO实现类的方法
   //都能取得同一个session
   Session session = HibernateSessionFactory.getSession();
   session.update(a);
}
}

按照我的意思是在业务层里调用DAO层进行一系列的数据库操作,整个业务当做事务处理

//就不写接口了
public class BankServices{
   AccountDAO ad = new AccountDAOImpl();
   //转账业务方法
   //from 出账账户, to 进账账户
   public boolean Transfer(Account from, Account to){
     session = HibernateSessionFactory.getSession();
     Transaction ts = null;
     try{
         ts = session.beginTransaction();
         ad.update(from);
         ad.update(to);
         ts.commit();
     }catch(Exception e){
         ts.rollback();
     }finally{
         session.close();
     }
     
   }
}

而按照他的说话是,业务层不处理事务,我问他像这个转账需要涉及到两个数据库操作怎么处理事务,他说要在AccountDAO里再写一个方法Transfer(),然后给DAO写一个代理类,在代理类里关闭连接,像这样。

public class AccountDAOImpl implements AccountDAO{
Session session = null;
Transaction ts = null;
public AccountDAOImpl(){

}
public AccountDAOImpl(Session session){
    this.session = session;
}
public void Transfer(Account from, Account to){
    try{
        ts = session.beginTransaction();        
        session.update(from);
        session.update(to);
        ts.commit();
    }catch(Exception e){
        ts.rollback();
    }
}
}

/**
*代理类
*/
public class AccountDAOProxy implements AccountDAO{

AccountDAOImpl adi = null;
public AccountDAOProxy(){
    Session session = HibernateSessionFactory.getSession();
    adi = new AccountDAOImpl(session);
}
public void Transfer(Account from, Account to){
    adi.Transfer(from, to);
    session.close();//session在代理类关闭
}
}


如果像这样的话还需要业务层么?这样DAO层很明显就有处理业务的逻辑,照这样写下去,那一个DAO不知道有多少方法,而业务层根本就不需要了,或者说仅仅就是调用这些方法,那有什么意思,当然我没有开发经验,我们公司的工程师是有的,我问他为什么要这样写,他说这是DAO设计模式的标准,我不知道这个设计模式是不是有问题,想问问有开发经验的人,到底事务是该在业务层处理还是在DAO层处理,谢谢 高分求答案!或者说我这样写有什么缺陷和不足。
事务 dao设计模式

------解决方案--------------------
业务层,service层,你是对的
------解决方案--------------------
引用:
业务层,service层,你是对的


不错。
------解决方案--------------------
service层
------解决方案--------------------
一个人一个习惯吧。。。
理论上dao层只负责数据的交互处理那一小部分,其他的都写在service。
人家那么说,即使不情愿,我建议还是按照人家说的去做吧。
如果一个框架都写错了,你那一处即使写对了,人家读起来也会觉得不舒服。
------解决方案--------------------
之前做这个时,习惯放在业务层。
DAO层负责数据的增删改,具体什么时候commit,还是rollback,这个在业务层通过事务去控制。
------解决方案--------------------
必须service层,dao层处理单个操作,service层处理很多的业务,其中可能有多个dao。
只有放在service层,才能保证同一个业务的多个dao操作同步的提交或回滚
------解决方案--------------------
  相关解决方案