三层还是多层？事务处理放在哪里？

首先，经典的三层架构形成的主要目的是什么？

无非就是划清表现层、业务逻辑层和数据层三者的关系。方便代码维护升级。相互解耦和！

当任何一层有内部变动时，不牵扯其他层的代码变动，这就是主要目的！

那么最近我总在思考一个问题：

DAL数据层是负责BLL逻辑层最终要执行的数据库操作。

而涉及到BLL业务逻辑需要事务处理时，到底事务处理代码是放到BLL层还是DAL层成了一个讨论比较多的话题。

我在一个博客里看到有处理办法是由BLL层创建一个固有的Tran对象来穿插所有事务操作。为每个DAL都创建Tran对象接手执行方法，接收BLL传来的Tran对象，所有事务执行完毕后，由BLL来执行RollBack操作。 博客地址：http://www.cnblogs.com/yyl8781697/archive/2012/02/01/SqlTransaction.html

这样做为整个项目带来的好处就是BLL层不牵扯数据层，那么BLL拿到的Tran对象算什么？

每个DAL层都接受Tran对象是否增加了代码量和维护成本呢？

每个DAL层都要判断是立即执行还是Tran，到最后的RollBack是交给BLL层来提交还是其他方式。

我想了很久，我们分层的主要目的是什么，又谈到文章开头部分。

分层的中心思想就是解耦和，方便维护跟升级。那么现在出现的事务处理到底是直接在BLL层获取Connection并在BLL内部执行所有Tran操作，还是获取一个Tran对象贯通所有DAL操作，最后RollBack呢。

总觉得这样做有点不伦不类！

所以最后我自己得出了一个自认为比较合适的方案。

那就是多写一个“Tran（事务层）”，专门存放所有事务操作。这样层次清晰，代码责任划分明显。也更方便维护。

这样的好处有如下几点：

1、BLL完全脱离任何跟DB相关的代码，专心处理业务逻辑。

2、不影响DAL的简单、单一数据库处理代码。

3、集中管理项目Tran事务操作部分。

胡言乱语这么多，也不知道大家能否理解我的想法，或者我这样做是否正确呢？

特地厚脸皮放在首页，让大家都来讨论一下，或者大家都有更好的方案来指点下我这个井底之蛙！ 见笑了！