关于DAO设计方式的疑问，事务该放在业务层处理还是DAO层
关于DAO设计模式的疑问，事务该放在业务层处理还是DAO层
我现在在学校安排的一家公司实习兼培训，今天和公司教我们的工程师讨论了一下DAO设计模式，关于事务处理该放在哪个层，公司的工程师说事务处理是放在DAO层的方法中，我认为事务应该放在业务层，当然我没有开发经验，但是我觉得在DAO层处理事务的话有些不合理，我觉得DAO层只是实现对于表的最基本的增删改查，而业务就是对数据库的一系列增删改查，在业务层通过调用DAO层的方法来完成相应的业务功能，比如转账，转出账户的余额需要减去转出的钱，转入账户的余额需要加上转入的钱，下面的代码可能不严谨，但仅仅是做为例子来讲解我的意思
按照我的意思是在业务层里调用DAO层进行一系列的数据库操作，整个业务当做事务处理
而按照他的说话是，业务层不处理事务，我问他像这个转账需要涉及到两个数据库操作怎么处理事务，他说要在AccountDAO里再写一个方法Transfer()，然后给DAO写一个代理类，在代理类里关闭连接，像这样。
如果像这样的话还需要业务层么？这样DAO层很明显就有处理业务的逻辑，照这样写下去，那一个DAO不知道有多少方法，而业务层根本就不需要了，或者说仅仅就是调用这些方法，那有什么意思，当然我没有开发经验，我们公司的工程师是有的，我问他为什么要这样写，他说这是DAO设计模式的标准，我不知道这个设计模式是不是有问题，想问问有开发经验的人，到底事务是该在业务层处理还是在DAO层处理，谢谢 高分求答案！或者说我这样写有什么缺陷和不足。
------解决方案--------------------
业务层，service层，你是对的
------解决方案--------------------
不错。
------解决方案--------------------
service层
------解决方案--------------------
一个人一个习惯吧。。。
理论上dao层只负责数据的交互处理那一小部分，其他的都写在service。
人家那么说，即使不情愿，我建议还是按照人家说的去做吧。
如果一个框架都写错了，你那一处即使写对了，人家读起来也会觉得不舒服。
------解决方案--------------------
之前做这个时，习惯放在业务层。
DAO层负责数据的增删改，具体什么时候commit，还是rollback，这个在业务层通过事务去控制。
------解决方案--------------------
必须service层，dao层处理单个操作，service层处理很多的业务，其中可能有多个dao。
只有放在service层，才能保证同一个业务的多个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层
------解决方案--------------------
一个人一个习惯吧。。。
理论上dao层只负责数据的交互处理那一小部分，其他的都写在service。
人家那么说，即使不情愿，我建议还是按照人家说的去做吧。
如果一个框架都写错了，你那一处即使写对了，人家读起来也会觉得不舒服。
------解决方案--------------------
之前做这个时，习惯放在业务层。
DAO层负责数据的增删改，具体什么时候commit，还是rollback，这个在业务层通过事务去控制。
------解决方案--------------------
必须service层，dao层处理单个操作，service层处理很多的业务，其中可能有多个dao。
只有放在service层，才能保证同一个业务的多个dao操作同步的提交或回滚
------解决方案--------------------