服务地点方便答案

【问题标题】：Service location for convenience服务地点方便
【发布时间】：2013-12-13 07:02:21
【问题描述】：

我对以下代码 sn-p 有 2 个问题：

public class Provider
{
    private static Provider _instance;

    /* Internals ommited. */

    public static Provider Instance
    {
        get { return _instance ?? (_instance = new Provider()); }
    }
}

public class Consumer
{
    private readonly Provider _dependency;

    public Consumer()
        : this(Provider.Instance)
    {
    }

    public Consumer(Provider dependency)
    {
        _dependency = dependency;
    }

    /* Internals ommited. */
}

1) 第二个构造函数使用依赖注入模式，第一个在做什么？服务地点？

2) 提供这种使用默认实例的重载 ctor 是常见的做法吗？还是有更好的方法来做这样的事情？（我想避免实现包装类）。

【问题讨论】：

这是一个单身人士。 en.wikipedia.org/wiki/Singleton_pattern
@kenny，Provider 引用了单个实例，但不是完整的单例。 Provider 应该将其默认构造函数定义为私有，否则任何人都可以通过说new Provider() 创建一个 Provider 实例。此外，Consumer 的默认构造函数使用 Provider 中定义的单个实例，但这并不意味着所有 Consumer 实例都会引用该实例。由于第二个构造函数，可以通过不同的提供者创建一个新的消费者。事实上，也有人可以扩展 Provider 并使用子类的实例创建 Consumers
@JonathanMoralesVélez 是的，这是一个糟糕的单身人士。

标签： c# .net dependency-injection service-locator

【解决方案1】：

1) 第一个构造函数使用静态依赖注入。这种模式允许从Provider 派生的类被注入用于测试目的，或者作为运行时默认Provider 实现的替代方案。 Provider 本身可能是一个服务定位器 - 这取决于它实际提供的对象或服务。

不过，在此示例中，Provider 被注入到 Consumer。那是依赖注入，而不是服务定位器（它需要一个类来确定它自己的依赖关系，从而导致它们之间的紧密耦合）。由于依赖注入，Consumer 类是否获得Provider 的默认实现或从它派生的类无关紧要。如果 a) Provider 是一个接口，并且 b) 如果客户端代码始终确定要注入哪个实例，而不是具有默认值，则这些类可能会更松散耦合。

2) 就我个人而言，我认为静态提供程序是一种代码味道，但它们确实有效，并且可能完全适合您的代码库。理想情况下，Provider 应该是由依赖注入框架注入的单例工厂。我目前正在处理的代码库中有静态提供程序，并且我正在以这种方式慢慢替换它们。 Consumer 应该有一个构造函数 - 第二个。

【讨论】：

这样的提供者设施——就像你所描述的——不是服务定位器吗？也许我对服务定位器的事情有完全错误的理解。 ;)
我已经更新了我的答案。如果您需要更多详细信息，我会添加一些。

【解决方案2】：

第二个构造函数使用依赖注入模式，是什么第一个在做什么？服务地点？

假设Provider 是依赖本身而不是某种注册表，那么不，它仍然是依赖注入。为方便起见，您只是为依赖项提供默认值。

提供这样一个使用默认实例？还是有更好的方法来做这样的事情？（我想避免实现包装类）。

这绝对没问题，但您可能需要考虑使用工厂方法作为默认构造函数的替代方法：

public static Consumer CreateDefault()
{
    return new Consumer(Provider.Default);
}

这样您就可以避免客户掩饰默认构造函数代表他们做出（可能很重要）选择这一事实。

【讨论】：

感谢工厂方法的提示。