Question

注入连接字符串与IDbConnection的实例有什么平衡？

我使用StructureMap将各种服务注入我的ASP.NET MVC应用程序，其中大多数服务需要LINQ-to-SQL查询的数据库访问。注入IDbConnection似乎比通用连接 string 参数更易于配置IoC，但是如果我没有明确地将连接包装在内，我担心会打开连接一个using块。

我应该注意哪些连接池的优点或缺点？

注入的连接字符串

using (var con = new SqlConnection(InjectedConnectionString))
{
    con.Execute("INSERT INTO Logs (...) VALUES (...)");
    using (var db = new MyDataContext(con))
    {
        var records = from p in db.Products
                      select p;
    }
}

注入IDbConnection

con.Execute("INSERT INTO Logs (...) VALUES (...)");
using (var db = new MyDataContext(InjectedConnection))
{
    var records = from p in db.Products
                  select p;
}

Answer 1

任何中等复杂的IoC容器（结构图）的特征是being able to control the lifetimes个对象。默认情况下，structuremap使用Transient生存期。这意味着它为每个对象图创建一个新实例。在实践中，这通常与每个网络请求相同（除非您将代码与container.GetInstance<T>()的用法一起使用）。

通过使用structuremap注入数据库连接等宝贵资源，您可以控制它们的生存时间。单个资源可以（如果您选择）在整个Web请求中重用，或者为每次使用创建新的资源。

此外，这些选择（以及配置）现在已外部化到注册表中，而不是通过代码将它们分散。如果必须更改连接的创建方式，则只需查看一个位置即可。总是首选具有单一职责的类。

就您的连接池问题而言，没有IoC容器会涉及连接池等细节。然而，它们确实有助于终生。 Structuremap将在任何Dispose()对象上调用IDisposable（嗯，它实际上是调用它的解释器）。

编辑：再次在连接池中，每个生命周期都有自己的规则，用于处理对象的方式和时间。瞬态依赖于CLR进行处置，但HttpRequestScoped确定性地在每个请求结束时处理对象。使用HttpRequestScoped会阻止您最大限度地增加连接数。

注入连接字符串与IDbConnection

注入的连接字符串

注入IDbConnection

1 个答案: