因此，根据我上一个问题的答案，如果在事务期间打开多个连接，即使这些连接都具有相同的连接字符串，事务也会从 LTM 提升到 DTC 。
那么，我的下一个问题是，可以采用哪些策略来避免这种“功能”？在我看来，根据资源使用情况，我想确保尽可能多地使用 LTM。在正确面向对象的业务逻辑层中，我能想到的唯一方法是在数据访问层创建一个请求级静态连接对象，并在调用之间共享该对象，直到请求完成（这里的隐含知识是业务对象实体是谨慎的并且不知道它们会被调用的顺序，另外一个事实是人们不希望将连接对象冒泡到业务对象层，因为那将是数据存储实现细节渗入另一层）。
还有其他人有什么想法不会完全破坏 n 层系统的层封装吗？
我使用的是 TransactionHelper 类更新 TableAdapter 中的所有命令，以将连接和事务替换为启动事务的 TableAdapter 中的连接和事务。您可以在 Scott Lanford 的博客CodeExperiment上找到一些执行此操作的代码，您可以根据需要对其进行调整。Ryan Whitaker 也有类似的做法。
请注意，自从我开始使用 LINQToSQL 后，我不再遇到这个问题。您可能需要考虑使用 LINQToSQL 或 nHibernate 作为替代解决方案。两者都可以很好地支持本地交易。
我不得不问，为什么要如此努力地避免 DTC？在这个或以前的答案中没有提到为什么，它看起来好像你可能患有过早的优化综合症。
正如 casper 所说，避免 DTC 可能为时过早，尽管它很重要。您可以使用静态工厂实现连接，以便简单地返回新对象，然后如果您确定有问题，您可以实现一种机制，可以将事务存储在 aa TLS（或 httpcontext，如果您在 ASP 中）中。并且不必更改任何代码。
这个问题实际上已经被问到并得到了回答，但是当我这样做时我找不到它，我会更新它。
我建议编写一个包装类来管理连接、事务、命令对象，这就是整个数据库。这是一种非常轻量级的 nHibernate。此类将提供 executeStatement(...)、executeQuery(...)、addParameter(...)、startTransaction(...) 等方法。
开始交易时，您可以提供一些（如果需要唯一的）标识符，您可以将所有后续关于同一交易的请求绑定到该标识符。然后，这个包装类将保存一个静态映射到哪个事务正在使用哪个连接运行，并会自动使用正确的映射或根据需要创建一个新的映射。
您将从这种方法中获得一些额外的功能，因为您将集中所有持久性内容：