.net中的事务处理到底应该放在BLL还是DAL里面啊？

RT```
.net里的事务处理应该放在BLL还是DAL里面呢？
我在网上看架构的时候看到这样一种提法：
除非事务放在存储过程中定义（纯数据库事务），否则（即使都是访问 DAL）都应放在 BLL 或 Domain 中实现
是正确的吗？

补充：不理解，事务不就是操作数据库的吗？为什么要放在逻辑层里呢？

答案：因为事务经常是由业务驱动的。

打个比方，现在有个OA系统，当新增用户时，业务方希望这个用户就进入了一个分组，并且属于某个指定的角色，换而言之，进User表、UserGroup表、UserRole表同时会进一条记录，这个业务必须是一个事务。

而对于写DAL层的人来说，他并不关心这个，他应该保证的是任何两个数据访问层的方法都能是一个事务。也许进User表是个独立的操作，也许进User和UserGroup表这两个操作是一个事务，写DAL层的开发人员应该保证任何两个方法的组合都能是一个事务（跨数据库的事务暂不在考虑之内）

甚至有些事务，未必全部都是数据访问操作，比如用户上传了一个文件到web服务器。
数据库新增了一条记录，记录用户aa上传了文件，并记录了上传文件的路径。
那么当删除这条记录的时候，同时还应该删除上传的这个文件，这两个操作，逻辑上是一个事务。

对于非数据库事务，相当于设计模式中的备忘录模式，需要自己完成类似于commit和rollback的操作。

至于我刚才所说的业务逻辑层实现事务，如果不用System.Transactions.Transaction类
，楼主可以考虑下如何实现

其他：只要是访问数据，不管是访问数据库还是访问文件都应该放在DAL（数据访问层），只有作逻辑判断时才放在BLL（逻辑判断层）！ 一般标准的DAL层是没有任何逻辑的！而事务是处理逻辑，因此应该放在BLL层。 业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层(DAL)：主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务。
(IDAL)它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL
(Model)实体和数据库表映射类
（Web）web网站项目
另外,站长团上有产品团购,便宜有保证 做判断的就是放在BLL。 做数据访问的不管是什么就放在DAL 

上一个：.net 请教一个有关Linq的问题 谢谢~！有图
下一个：.net framework 4.0安装失败