IoC（结构图）最佳实践答案

【问题标题】：IoC (StructureMap) Best PracticeIoC（结构图）最佳实践
【发布时间】：2010-09-20 15:08:56
【问题描述】：

根据我（可能是微薄的）理解，在控制器/演示器中的方法中间执行此操作被认为是不好的做法，因为它会在 StructureMap 和演示器之间创建依赖关系：

void Override() {
    ICommentForOverrideGetter comm = StructureMap.ObjectFactory.GetInstance<ICommentForOverrideGetter>();

因为这个依赖应该通过构造函数注入到presenter中，你的IoC容器将它连接起来。在这种情况下，尽管每次运行此方法时我的代码都需要 ICommentForOverrideGetter 的新副本。这是上述最佳实践的例外情况，还是我应该重新考虑我的架构的情况？

【问题讨论】：

标签： inversion-of-control structuremap ioc-container

【解决方案1】：

据说计算机科学中没有问题是不能通过多一层间接解决的：

如果您只是不想在演示者中使用依赖项，请注入工厂接口，真正的实现可以执行 new CommentForOverrideGetter 或其他任何操作。

编辑：

“当我认为复杂性/收益比太高时，我可以忽略最佳实践”：我也没有，但正如我在 cmets 中所说，我不喜欢在我想要的代码中对 IoC 容器的硬依赖单元测试和演示者就是这样的情况。

根据您的 ICommentForOverrideGetter 所做的，您也可以使用简单的 CommentForOverrideGetter.CreateNew() 但由于每次调用都需要一个新实例，我怀疑至少某种与创建相关的逻辑？还是有状态的“服务”？

【讨论】：

我非常喜欢这句话（来自 David Wheeler）。我知道我可以做到这一点，但是男孩，对于如此简单的事情来说，这似乎太多了。在您描述的情况下，IoC 容器不应该消除对工厂的需求吗？
IoC 调用并没有特别困扰我，我只是想了解更多有关 IoC 最佳实践的信息。当我认为复杂性/收益比太高时，我可以忽略最佳实践，我只是想确保没有遗漏任何其他内容。
就我个人而言，我只是不想在我的演示者中硬依赖 IoC 容器（或者更笼统地说：我想要单元测试的类）。
这是一个非常简单的案例，我担心我的问题在描述时会显得很愚蠢，但对我来说最重要的是找出最佳实践，以便我可以将它们应用于更复杂的事情，例如有状态服务。我不是一个新程序员，我只是在游戏后期才开始单元测试/IoC。无论如何，我评论。只是一个非常简单的视图（表单），它获取评论并触发演示者捕获的事件。在某种情况下。当事件触发时，演示者将执行 X，在其他情况下它将执行 Y。所以我刚刚在需要时获取了它，然后连接事件
如果您不想为单元测试设置 IoC 的复杂性，您应该使用工厂。另一方面，在 StructureMaps 情况下，一个简单的 ObjectFactory.Inject(T instance) 就足够了。我不认为任何人都可以在这里给你一个明确的答案，因为每个人都有不同的偏好:)

【解决方案2】：

如果你坚持在你的方法中做服务定位，你至少应该将容器注入到你的控制器中，这样你就可以消除静态方法调用。添加StructureMap.IContainer 类型的构造函数参数并将其存储在字段变量中。 StructureMap 将注入适当的容器。然后，您可以在该容器上调用 GetInstance()，而不是 ObjectFactory。

【讨论】：