Question

经过多次踢和尖叫之后，我开始接受DI，尽管随着依赖关系的增长，SL看起来更加清晰。

然而，对于DI来说，IMO还是一个显着的阻碍因素：

当你无法控制对象的实例化时，DI是不可能的。在ASP.NET世界中，例子包括：HttpModule，HttpHandler，Page等。

在上面的场景中，我们将使用静态服务位置来解析依赖关系，通常是通过HttpContext.Current，它总是从当前线程推断出范围。所以，如果我们要在这里使用静态SL，那么为什么不在其他地方使用它呢？

答案是否如此简单：咬牙并在必要时使用SL（如上所述），但尝试并支持DI？如果是这样的话：不使用静态SL只会破坏整个应用程序的一致性吗？基本上在其他地方撤消DI的辛勤工作？

Answer 1

有时你无法避免紧密耦合，就像在你的例子中一样。但是，这并不意味着您需要接受它。相反，通过封装混乱来隔离它并将其从日常生活中分解出来。

例如，如果我们想要当前的表单身份验证用户，我们没有太多选择，只能访问HttpContext.Current.Request.User.Identity.Name。但是，我们可以选择在哪里拨打电话。

HttpContext.Current是解决问题的方法。当我们直接从我们使用结果的地方调用它时，我们在同一个地方声明问题和解决方案：“我需要当前的用户名，它被声明为来自当前的HTTP上下文。”这混淆了两者的定义，并且不允许对同一问题采用不同的解决方案。

我们所缺少的是对我们正在解决的问题的明确阐述。对于此示例，它将类似于：

确定发出当前请求的用户

我们使用HttpContext.Current甚至用户名的事实不是核心问题定义的一部分;它是一个实现细节，仅用于使需要当前用户的代码复杂化。

我们可以通过界面表示检索当前用户的意图，无需实现细节：

public interface IUserContext
{
    User GetUser();
}

我们直接调用HttpContext.Current的任何类现在都可以使用此接口，由容器注入，以保持DI良好性。如果一个类在其构造函数中接受IUserContext而不是从其公共API中看不到依赖项，那么它也更有意图揭示。

实现将静态调用隐藏在一个不再损害我们对象的地方：

public class FormsUserContext : IUserContext
{
    private readonly IUserRepository _userRepository;

    public FormsUserContext(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }

    public User GetUser()
    {
        return _userRepository.GetByUserName(HttpContext.Current.Request.User.Identity.Name);
    }
}

Answer 2

良好的代码库也是对最小解决方案的偶然限制包含在一个小区域的代码库。缺乏DI的可能性部分解释了从ASP.NET到MVC的转变。使用HttpHandlers，我通常有一个HttpHandler Factory，它是唯一一个让它“手”变脏并从容器中实例化HttpHandlers的类。

许多DI容器都有某种BuildUp方法来对已经实例化的对象执行setter注入。如果您有服务位置，请尝试将其隔离到您的应用程序中，这纯粹是基础架构问题。然后它将成为环境限制的缓冲领域。

简而言之，某些SL不会使您的工作无效，但请确保SL位是基础结构且包含良好。

Answer 3

以@ flq的答案提供一个例子。

我正在开发一个ASP.Net MVC项目，该项目大量使用Ninject。有几个地方，我要么不能使用DI（扩展方法），要么更干净，而不是使用SL（所有控制器的基类，构造函数注入会使控制器的所有构造函数变得混乱）。

所以，作为妥协，我使用轻微的混合：

public interface IServiceLocator
{
    T Create<T>();
}

public class NinjectServiceLocator : IServiceLocator
{
    private readonly IKernel kernel;

    public NinjectServiceLocator(IKernel kernel)
    {
        this.kernel = kernel;
    }

    public T Create<T>()
    {
        return kernel.Get<T>();
    }
}

public class ServiceLocator
{
    private static IServiceLocator current;

    public static IServiceLocator Current
    {
        get
        {
            return current;
        }

        set
        {
            current = value;
        }
    }

    public T Create<T>()
    {
        return current.Create<T>();
    }
}

它可能不是最好的选择，或严格的SL模式，但它适用于我。附加接口允许我交换定位器本身进行测试。 IKernel是Ninject的主要DI对象，它被配置，所以用你自己的框架代替，因为我遇到的大多数都有类似的核心。

Answer 4

这些情况下的典型方法是编写一个使用Service Locator的通用基础架构级包装器/适配器，但为使用此适配器的应用程序级类提供干净的IoC。

我这样做是为了在HttpModules和Providers中启用IoC，这两种情况下框架不允许控制实例化。类似的方法可以用于其他类似的实体。

这里的要点是这样的包装器/适配器代码是可重用基础架构的一部分，而不是您的应用程序级代码。通常不建议使用应用程序级代码中的服务位置。

某些容器提供的“BuildUp”功能对于这些限制来说是一个糟糕的解决方法。 BuildUp不允许您重新获得对实例化的控制，因此您将无法使用某些容器功能，例如代理。

如果不能使用依赖注入怎么办？

4 个答案: