当我在 DataContext 中手动打开连接时应遵循什么模式

Question

Linq2Sql 不支持存储过程的表值参数 (1， <一href="https://stackoverflow.com/questions/1019414/linq-to-sql-with-stored-procedures-and-user-define-table-type-parameter">2）。

因此，我在 DataContext 中添加了对表值参数的丑陋支持（只是为了保持一致，并且仍然能够从同一数据上下文中调用我的过程）。

我手动调用 this.Connection.CreateCommand()，将其强制转换为 SqlCommand（因为无论如何它都会是 SqlCommand）列出所有参数，包括 SqlDbType.Structured 参数和 ExecuteNonQuery 参数。

这工作正常。
但是。
在我的辅助方法中，我必须打开上下文连接，因为它可能已关闭。 因为我手动打开连接，所以我必须手动关闭它吗？

我已经经历过这些：
我是否必须关闭如果我使用 Linq，请手动连接 SQL？
我应该何时处置数据上下文
如果我使用 DataContext，何时启动与数据库的连接？< /a>

但他们实际上并没有回答我的问题。我知道枚举结果时连接已关闭，但它比这更复杂。与枚举结果相反，调用方法不是只读操作。
此外，如果存在环境事务，DataContext 肯定不会在第一个方法调用后关闭连接：

using (var ambient_tran = new System.Transactions.TransactionScope())
{
    using (var dx = new SomeDataContext()) 
    {
        dx.CallMethodOne(foo, bar);
        dx.CallMethodTwo(bar, baz); // executed on same connection and same transaction,
                                    // can see uncommitted data entered by CallMethodOne
    }

    ambient_tran.Complete();
};

正因为如此，我不确定什么是正确的事情关于连接要做的事情。
我只是打开连接并让 DataContext 管理其生命周期，还是有可遵循的模式？

---

编辑：

实验表明，如果我只是将其保持打开状态，它会表现良好并自动尊重环境事务（如果有）。不过，我更愿意就此提供可靠的建议。

Answer 1

如果不需要分布式事务，请避免使用 System.Trasactions。相反，请参阅我的 TextMetal 项目、示例代码，并注意 Plumbing 命名空间。如果您有疑问，请给我发电子邮件。没有 MSDTC 的手脚，只是正确生成的 ADO.NET/LINQ to SQL、工作单元模式和一些精心设计的数据访问代码！

如果有令人信服的理由使用 System.Transactions，那么我建议您仍然尽快关闭连接，因为事务协调器将在连接释放到池后管理提交/回滚。