IoC(结构图)最佳实践

发布于 2024-09-24 07:57:07 字数 381 浏览 0 评论 0原文

根据我(可能很肤浅)的理解,在控制器/演示者中的方法中间执行此操作被认为是不好的做法,因为它在 StructureMap 和演示者之间创建了依赖关系:

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

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

By my (likely meager) understanding, doing this in the middle of a method in your controller / presenter is considered bad practice, since it creates a dependency between StructureMap and your presenter:

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

since this dependancy should be injected into the presenter via the constructor, with your IoC container wiring it up. In this case though my code needs a fresh copy of ICommentForOverrideGetter every time this method runs. Is this an exception to the above best practice, or a case where I should re-think my architecture?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

当爱已成负担 2024-10-01 07:57:07

据说,计算机科学中没有任何问题不能通过多一层间接解决:

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

编辑:

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

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

It is said that there is no problem in computer science which cannot be solved by one more level of indirection:

If you just don't want the dependency in your presenter, inject a factory interface, the real implementation could do new CommentForOverrideGetter or whatever.

Edit:

"I have no problem ignoring best practices when I think the complexity/benefit ratio is too high": Neither do I, but as I said in the comments, I don't like hard dependencies on IoC containers in code I want to unit test and presenters are such a case.

Depending on what your ICommentForOverrideGetter does, you could also use a simple CommentForOverrideGetter.CreateNew() but as you require a fresh instance per call, I'd suspect at least some kind of logic associated with the creation? Or is it a stateful "service"?

梦在深巷 2024-10-01 07:57:07

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

If you insist on doing service location in your method, you should at least inject the container into your controller, so that you can eliminate the static method call. Add a constructor parameter of type StructureMap.IContainer and store it in a field variable. StructureMap will inject the proper container. You can then call GetInstance() on that container, instead of ObjectFactory.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文