Question

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

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

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

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

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

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

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

所以，这里有所有背景问题：

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

注意：这可能是也可能不相关：我们在一个特殊的基页中调用ObjectFactory.BuildUp（this），这些页面已被转换为使用新的体系结构 - ASP.Net没有提供好的接入点。

Answer 1

好的，最后这并不是那么难。这是代码：

var instantiatedObject = new PropertyType();

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

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

ASP.Net StructureMap以前将对象注入依赖关系

1 个答案: