ASP.Net StructureMap 将以前的对象作为依赖项注入答案

【问题标题】：ASP.Net StructureMap Injecting Previously Objects as DependenciesASP.Net StructureMap 将以前的对象作为依赖项注入
【发布时间】：2011-12-10 20:52:24
【问题描述】：

（TLDR？跳到最后几段的问题...）

我有一个经典的 ASP.Net 站点，它最初是围绕数据访问层构建的，该层由围绕 ADO.Net 的静态方法组成。最近，我们引入了由接口分隔的抽象层，这些接口由 StructureMap 粘合在一起。然而，即使在这种新的分层方法中，存储库层仍然包裹着旧的静态 ADO.Net 类（我们不准备承担实现 ORM 的任务同时重新组织我们的应用程序架构）。

这一切都很好 - 直到今天。在调查我们最近遇到的一些意想不到的性能问题时，我们注意到了一些关于我们的数据访问类的事情：

我们的 SqlDataConnection 实例并不总是被关闭。
连接对象存储在静态变量中。

上述两种做法都是不好的做法，可能会严重影响我们的性能问题。在静态变量中设置连接的原因是为了在数据访问方法之间共享它们，这在理论上是一个好主意 - 这只是一个糟糕的实现。

我们的解决方案是将静态数据访问类/方法转换为对象 - 我们的核心 DataManager 类在请求开始时被实例化一次并在结束时处理一次（通过 Web 层中的新 PageBase 类 - 很多我们的代码还没有分成层）。这意味着我们有一个数据访问类的实例，该实例用于请求的整个生命周期，因此只有一个连接。

当我们使用较新的分层架构到达站点区域时，问题就开始了。使用较旧的代码，我们可以将 DataManager 实例的引用直接从后面的代码传递给数据访问层，但是当层被接口分开并且只有 StructureMap 知道不同的部分时，这将不起作用。

所以，在所有背景之外，这里的问题是：

StructureMap 是否可以通过将先前实例化的对象作为依赖项传递来创建实例 - 在单个 ASP.Net 页面生命周期的上下文中？
如果可能，如何实现？我在搜索中没有看到任何明显的东西，过去也不必这样做。
如果不可能，有什么替代解决方案可以解决我上面描述的问题？

注意：这可能是相关的，也可能是不相关的：我们在一个特殊的基础页面中调用 ObjectFactory.BuildUp(this)，用于那些已经转换为使用新架构的页面 - ASP.Net 没有提供一个好的接入点。

【问题讨论】：

标签： asp.net structuremap

【解决方案1】：

好吧，这最终并没有那么难。代码如下：

var instantiatedObject = new PropertyType();

ObjectFactory.Configure( x => 
    {
        x.For<IPropertyType>().Use( () => instantiatedObject );
        x.SetAllProperties( p => p.OfType<IPropertyType>() );
    }
);

我们只是把它放在我们的 PageBase 类中 ObjectFactory.BuildUp( this ) 行之前。像这样将 IoC 配置放在主代码中感觉有点脏——但它是经典的 ASP.Net，没有太多替代方案。我想我们可以提供一些抽象。

【讨论】：