引用一下别人的导读：
在实际开发工作中，执行一个事件，然后调用另一接口插入数据，如果处理逻辑出现异常，那么之前插入的数据将成为垃圾数据，
我们所希望的是能够在整个这个方法定义为一个事务，TransactionScope 类提供一个简单方法，通过这一方法，您不必与事务本身交互，
即可将代码块标记为参与某个事务。TransactionScope对象创建了一个事务，同时将该事务设置给Transaction类的Current属性。
一、TransactionScope的优点
1、使用起来比较方便．TransactionScope可以实现隐式的事务,使你可以在写数据访问层代码的时候不用考虑到事务，而在业务层的控制事务．
2、可以实现分布式事务,比如跨库或MSMQ.
二、TransactionScope缺点
1、性价比不高.比如,你只是在"Scope"里控制一个库的事务.用"TransactionScope"就有点浪费了.
2、一般情况下只要你使用"TransactionScope",都要配置MSDTC,要配防火墙,要开139端口.这个端口不可以更改
三、如果你不得不用分布式事务，那也得琢磨琢磨
1.这步操作一定得在事务当中吗？这步操作如果没完成或者失败了，值得回滚整个事务吗？难道没有优雅的补偿措施或者容错措施？
2.分布式事务涉及到的点，必须的这么多？必须得实时的操作这一大串？不能通过通知类操作去精简掉某些点？
3.在发起分布式事务之后，你是不是做了事务无关的操作，尽管这些操作跟事务无关？（如，读取数据、计算、等用户返回消息、等其他模块的调用返回等等）要知道事务应该尽快结束。
4.你没有把一些读操作也算在事务里面了吧？这是很容易犯的错误，你在事务中Enlist了一个select 操作。
5.你的操作，某些步骤可以等全部操作完成之后再执行.这类操作具有明显的通知类特点。通知类操作是说，我给你一个通知，并且我保证通知到了你；
你必须吃下这个通知，并且保证处理成功，但是你不必我一通知你你就处理。这样的操作很明显可以用另外一个任务去搞。
四、使用分布式事务注意如下几点
1：确保参与事务的machine开启了分布式事务支持；
2：如果machine开启了防火墙，需要设置msdtc进程为例外；
3：参与事务的machine不能跨域（如果跨域，目前微软还没有确切的解决方案）；
4：多数据库时才使用分布式事务，如果是同一个数据库，最好使用SqlTransaction.
1、先添加System.Transactions的引用（需要添加Net程序集）
C#调用时的代码如下：
using System.Transactions; using (TransactionScope scope = new TransactionScope()) { //trancation one do something... var dbo1 = DBFactory.GetDBFacade(DBConnectionStringName.YSL_BusinessTravelTrade_ReadWrite); string sql1 = "UPDATE dbo.TestUser SET name='ccc' WHERE id = 2"; dbo1.ExecuteNonQuery(CommandType.Text, sql1); //trancation two do something... var dbo = DBFactory.GetDBFacade(DBConnectionStringName.YSL_BusinessTravel_ReadWrite); string sql = "UPDATE dbo.TestUser SET name='ccc' WHERE id = 2"; dbo.ExecuteNonQuery(CommandType.Text, sql); //submit scope.Complete(); }
2、设置web服务器及sql服务器环境配置
控制面板->系统和安全->管理工具->组件服务
（WEB服务器和SQL服务器都需要配置此项）
控制面板->系统和安全->管理工具->服务
（WEB服务器和SQL服务器都需要配置此项）
控制面板->系统和安全->Windows防火墙
（WEB服务器和SQL服务器都需要配置此项）
3、MSSQL配置
对服务器连接，右键->属性
4、配置Hosts（只配置WEB服务器即可，如果不行，在SQL服务器上也配置上）
C:WindowsSystem32driversetc
hosts文件，用记事本打开
（在WEB服务器上的Hosts文件中需要配置SQL服务器的信息）
（如果测试通不过，在SQL服务器上的Hosts文件中配置上WEB服务器的信息）
