注意
　　在 ManualTxn 方法中，事务处理控件通过 ADO.NET SQLTransaction 对象来实现。
　　在 ManualTxn_COM+_IP 和 ManualTxn_COM+_OP 中，都是使用 ADO.NET SQLTransaction 对象来控制事务处理，而程序集则由 COM+ 分别配置为库和服务器程序包。
　　包含 AutomaticTxn 和 AutCompleteTxn 实现的 .NET 程序集使用 COM+ 进行注册。在 AutomaticTxn 中，我们显式提交或中止事务处理，而在 AutoCompleteTxn 中，则由 .NET 程序集来确定提交或中止当前事务处理。
　　在 AutomaticTxn_IP 和 AutoCompleteTxn_IP 中，包含程序集的 COM+ 应用程序是一个由库激活的应用程序，所以该应用程序在创建它的客户端进程中运行。
　　在 AutomaticTxn_OP 和 AutoCompleteTxn_OP 中，包含程序集的 COM+ 应用程序是一个由服务器激活的应用程序，所以它在代理进程 (dllhost.exe) 中运行。
　　ManualTxn 和 ManualTxn_COM+_IP 的性能非常类似，这是因为与 COM+ 相互操作相关的成本很小。

　　AutomaticTxn_IP 与上述方法相比明显缓慢，这是因为使用分布式事务协调器 (DTC) 设置事务处理的成本要比在事务处理中完成所有工作（11 次插入）的成本高。除了 DTC 外，AutomaticTxn_IP 中还因 COM+ 的相互操作和上下文转换而产生了一些额外的成本，这一点我们从上面可以看到。
　　AutomaticTxn_IP 提供的性能要比 ManualTxn_COM+_OP 和 AutomaticTxn_OP 提供的性能好，因为在后者中，COM+ 应用程序被配置为服务器程序包，而服务器程序包在一个单独的代理程序 (dllhost.exe) 中运行，因而需要数据封送。
　　正如我们所预计的那样，AutoCompleteTxn_IP 和 AutoCompleteTxn_OP AutoComplete 版本分别与 AutomaticTxn_IP 和 AutomaticTxn_OP 版本的运行状况类似。

图 4：InsertOrder_DataSet(Order=1， Details=100)

　　与第一个测试一样，在大型事务处理（101 次插入）中，事务处理控件模型之间的性能差别大大降低了。而且，与 DTC 和数据封送相关的成本也因大型事务处理的分摊而降低了。　

　　总结
　　每个事务处理模型在应用程序性能和代码可维护性方面都各有侧重，因此它们适用于不同的方案。
　　运行存储过程中实现的数据库事务处理可以提供好的性能，因为它只需要一次数据库往返操作。虽然它提供了很好的性能和灵活性，但用户还需要在 Transact-SQL 中进行编码，而这并不像在 .NET 中那样简单。
　　使用 ADO.NET 事务处理对象的手动事务处理很容易进行编码，而且用户可以使用显式的指令开始和结束事务处理，因而在控制事务处理的范围时具有很大的灵活性。与这种方便和灵活性相对应的是，ADO.NET 手动事务处理需要进行很多次往返操作，至少等于事务处理中要执行的操作数加上开始和结束事务处理所需要的往返操作次数。
　　由于和 DTC 的交互以及和 COM 的相互操作，自动事务处理模型还会产生一些额外开销。而与 DTC 相关的成本可以分摊到整个事务处理过程中，如测试中所示。使用此模型的优点是大大简化了应用程序的设计并减少了编码需求。如果事务处理跨越多个能够识别事务处理的资源管理器（可能包括 SQL Server 数据库和 MSMQ 消息队列），那么只能选择自动事务处理。