看你需求，稍微麻烦可能是缺点，那这么做的优点有哪些

楼主可以参考SOD框架的源码和使用方式，可以自动使用事务的连接的。

所谓”业务逻辑层开启事务“是什么意思啊？你能说清楚吗？既然你在业务逻辑层的描述时就直接使用你的 DAL 层概念了，为什么自自然然地使用一个具体DAL概念又纠结了呢？！

不管你牵扯到什么“接口啊、对象啊、默认的全局事务对象啊”，都是在这里使用 DAL 层概念。没有一点点新鲜的东西。

“分层”就让人不落地了、飘飘然了？

在业务逻辑层，你没有谈业务上的“长事务”的自定义逻辑，却来纠结一个比较低级的“关系数据库事务”概念。那么在业务逻辑层既然你要直接用低级的概念来组成业务逻辑说明，那么你编程时就得如此与之对应地使用一个 DbTransaction 对象作为参数（不管是之际准确地传递，还是让系统不管你需不需要都默认地用一个全局的参数）。

这里之所以这样编程，是因为我们不得以。因为我们能讨论的范围就是这个低级，就必须用它作为参数，躲不开绕不开了。

也没那么麻烦啊，不就是传一个参数嘛！

但如果如你说的“每个dal的方法都要传参数”，这显然是可以优化的，即可以优化为一个Dal初始化时传入一次参数，之后调用Dal类方法就不用传参数了。比如：

using (var connSource = dbSource.GetConnection())

                {

                    using (var connDestination = dbDestination.GetConnection())

                    {

                        DataSync sync = new DataSync(connSource, connDestination);



                        //下载

                        sync.SyncOrg();

                        sync.SyncEmployer();

                        sync.SyncProduct();

                        sync.SyncCustomer();

                        sync.SyncGoldlog();

                        sync.SyncSale();

                        sync.SyncSaleCredit();

                        

                        //Sql任务

                        sync.SqlTask();



                        //上传

                        sync.UpdateCustomer();

                    }

                }

实际应用：
表单的保存，dal层两个方法，保存表头实体和保存明细实体，bll处理逻辑得到对应的表头实体对象，得到明细实体的list，然后开启事务，调用dal的两个方法保存。这种情况下bll需要传入dbconnection还需要传入dbtransaction

无论ado还是EF，都有全局的事务，所以你可以选择全局事物

另一种方式，改写为链式调用，比如
doA()
     .doA()
      .事务()
     .run()

你是要问 transactionscope？

在.net 1.1的时代，还没有TransactionScope类，因此很多关于事务的处理，都交给了SqlTransaction和SqlConnection，每个Transaction是基于每个Connection的。这种设计对于跨越多个程序集或者多个方法的事务行为来说，不是非常好，需要把事务和数据库连接作为参数传入。在.net 2.0后，TransactionScope类的出现，大大的简化了事务的设计.
TransactionScope 会将当前的 Transaction 存储到线程静态字段中。当稍后实例化 SqlCommand 时（在此 TransactionScope 从线程局部存储中删除之前），该 SqlCommand 会检查线程静态字段以查找现有 Transaction，如果存在则列入该 Transaction 中。通过这种方式，TransactionScope 和 SqlCommand 能够协同工作，从而开发人员不必将 Transaction 显示传递给 SqlCommand 对象。

结帖。。。

然而，TransactionScope诸多限制，并不是主流的事务控制方法，
我最开始还用它，后来废弃了，因为我用的EF Extends不支持，还有提升为分布式事务的隐患