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

关于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操作同步的提交或回滚
------解决方案--------------------

引用:

Quote: 引用:

业务层，service层，你是对的

实际开发中是这样做的么？

实际开发中也基本是这样的。业务层里的一个业务就有可能涉及对很多地方的增删改，这些增删改基本都是同一个业务的一步出错就要全部回滚的，只有这个业务里面的都完成了才算是这块做成功了
[解决办法]
当然是在业务层！
[解决办法]
正确做法是在业务层实现事务处理。

现在比较流行的做法是通过AOP实现。
业务层无须关心事务处理。如果需要回滚的话，只要抛出一个异常即可。如果不需要回滚，让方法正常结束。
DAO层也只需要提供单独的增删改查方法。
事务处理由框架或共通实现。
具体可以参考Spring Framework。

关于DAO设计方式的疑问事务该放在业

热点推荐