静态方法中的统一

Question

一个可能很简单的问题，但很奇怪为什么我不知道该怎么做：

Unity (PRISM) 和静态方法。在这种特殊情况下，需要使用扩展方法。但一般来说，如何在静态方法中访问“统一提供的实例”。想想例如我想访问一个日志服务来记录我在静态方法中所做的一些事情。使用它时我真的必须将引用传递给日志服务吗？

示例（接近实际问题）

public static void HookupPrismEvent(ref UIElement, ILogger log) {...}

看起来很奇怪，我想我错过了一些东西，比如 Container.Resolve （静态解析）。还没有找到任何东西，但容器、统一或静态并不是世界上最好的搜索词。也许我应该尝试一下，但仍然感觉有点“奇怪”。

那么关于如何和如果在静态方法中使用 DI 有什么评论吗？

克里斯

编辑-好的，回答后的当前方法：EDIT2，经过思考后，删除了容器，提供“需要的东西”....

  public static void AttachPrismEvents(this UIElement element, IEventAggregator eA)
    {
        var ev = eA.GetEvent<KeyPressedEvent>();
        element.KeyDown += ((sender, e) => ev.Publish(e));
    }

或者，使用日志记录：

  public static void AttachPrismEvents(this UIElement element, ILogger log, IEventAggregator eA)
    {
        log.Debug("Doing stuff");
        var ev = eA.GetEvent<KeyPressedEvent>();
        element.KeyDown += ((sender, e) => ev.Publish(e));
    }

Answer 1

静态类型和成员通常是所有 DI 的敌人。

从技术上讲，您可以有一个静态 Resolve 方法，但这不是 DI，而是一种称为服务定位器的模式。然而，许多人（包括我自己）认为服务定位器是一种反模式，原因如下：

• 它对 API 的使用要求做出隐式假设（调用者不知道必须正确配置服务定位器才能调用成员）
• 嵌套容器变得不可能
• 它引入了对服务定位器本身的冗余依赖

如果你必须有一个静态方法，你应该通过方法注入传递依赖，但我认为重新考虑整体 API 设计通常更有利。通常，所需的功能可以建模为输入参数之一的成员。