2

我可能描述错了，但这是我的困境，我有一系列接口，比如IBreadcrumbRetriever. 它们的实现完全不同，具体取决于它们在我的站点上的位置，我用它HttpContext.Current.Request.Path来确定。

因此，在我的具体类中，我现在有几个 if 语句来确定要返回的项目（为简单起见，我们说List<string>）。这对我来说是一种代码味道。

我真正想要的是，不知何故，我觉得 IoC 和 Castle Windsor 可以在这里帮助我，确定用户点击页面是否满足特定条件并将正确的容器绑定到该条件。所以我会有类似的东西

if (HttpContext.Current.Request.Path == some condition)
     IBreadcrumbRetriever is ImplementedBy IsInProductAreaRetriever

这是一个好主意吗？如果是这样，我会怎么做？还是我像面包屑工厂类一样创建并使用“ .DependsOn(HttpContext.Current.Request.Path)”扩展来实现我正在做的事情？

4

1 回答 1

0

这取决于您的应用架构是否适合依赖注入。

不熟悉 Castle Windsor 但一般来说，如果无法在组合根（应用程序启动）处解决依赖关系，我认为注入适用于当前 http 上下文的工厂实现没有任何问题。

例如，在 ASP.NET 应用程序中，您的组合根目录将位于global.asax. 在那里你可以将一些绑定IBreadcrumbRetrieverFactory到一个BreadcrumbRetrieverFactory实现。new建立不属于核心框架的类（以及少数几个）通常是错失 DI 机会（以及紧密耦合）的标志。

IoC 容器和 DI 不是灵丹妙药：依赖注入只是一种设计模式（想想构造函数注入、只分配private readonly字段的构造函数 - 类型的依赖项），而 IoC 容器（所有这些）只不过是便于布线的工具使用具体实现的依赖关系。考虑到这一点，Castle Windsor 没有什么是你用穷人的 DI做不到的：关键在于尽早推动依赖项的实例化——即在应用程序启动时，组合 root。

当依赖项是“动态的”时，例如，当有一个逻辑决定是否ISmurf应该执行HappySmurf或GrumpySmurf时，最好的办法是，恕我直言，注入ISmurfFactory依赖项而不是 a ISmurf，并将工厂的接线推到组成根。

于 2013-06-19T22:21:08.933 回答