IOC（StructureMap）

通过我的（可能是微薄的）理解，在你的控制器的方法的中间这样做/演讲被认为是不好的做法，因为它创建StructureMap和您的主持人之间的依赖关系最佳实践：IOC（StructureMap）

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

由于这种依赖性应通过构造函数注入演示者，并使用IoC容器将其连接起来。在这种情况下，尽管每次运行此方法时我的代码都需要ICommentForOverrideGetter的全新副本。这是上述最佳实践的例外，还是我应该重新考虑我的架构的情况？

来源

2010-09-20 Adam Rackis

据说，有计算机科学没有什么问题不能由一个间接多个层次来解决：

如果你只是不想在你的演讲的依赖，注入一个工厂接口，真正的实现可以做新的CommentForOverrideGetter或其他。

编辑：

“我没有问题，忽略了最佳实践的时候我觉得复杂/效益比过高”：我也不知道，但我在评论中说，我不喜欢依赖难在代码中的IoC容器上我想单元测试，演示者就是这种情况。

根据你的ICommentForOverrideGetter做什么，你也可以使用一个简单的CommentForOverrideGetter.CreateNew（），但是如果你需要每次调用一个新的实例，我会怀疑至少有某种与创建相关的逻辑？或者它是一种有状态的“服务”？

来源

2010-09-20 15:17:56 Maxem

我绝对喜欢这种说法（来自David Wheeler）。我知道我可以做到这一点，但男孩，这似乎太简单的东西太多的开销。 IoC容器是否应该像您所描述的那样消除对工厂的需求？ – 2010-09-20 15:21:16

IoC电话并不是特别困扰我，我只是想了解更多关于IoC最佳做法。当我认为复杂度/效益比太高时，我毫无疑问地忽视了最佳实践，我只是想确保没有其他东西丢失。 – 2010-09-20 15:22:57

个人而言，我只是不希望在演示者中对IoC容器产生严重依赖（或者更普遍：我想单元测试的类）。 – Maxem 2010-09-20 15:25:01

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

来源

2010-09-20 18:42:06

IOC（StructureMap）

回答

相关问题