如果不能使用dependency injection怎么办？
在经过多次踢和尖叫之后，我开始接受DI，尽管随着依赖关系的增长，SL看起来更加清晰。
然而，对于DI来说，IMO仍然有一个显着的阻碍：
当您无法控制对象的实例化时，DI是不可能的。 在ASP.NET世界中，示例包括：HttpModule，HttpHandler，Page等。
在上面的场景中，我们将使用静态服务位置来解析依赖关系，通常是通过HttpContext.Current ，它总是从当前线程推断出范围。 所以，如果我们要在这里使用静态SL，那么为什么不在其他地方使用它呢？
答案很简单：咬牙并在必要时使用SL（如上所述），但尝试并支持DI？ 如果是这样的话：一次性使用静态SL可能会破坏整个应用程序的一致性吗？ 基本上在其他地方撤消DI的辛勤工作？
有时你无法避免紧耦合，就像在你的例子中一样。 但是，这并不意味着您也需要接受它。 相反，通过封装混乱来隔离它并将其从日常生活中分解出来。
例如，如果我们想要当前的Forms Authentication用户，我们没有太多选择，只能访问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); } }
良好的代码库也是对最小解决方案的偶然限制包含在一个小区域的代码库。 缺乏DI的可能性部分解释了从ASP.NET到MVC的转变。 使用HttpHandlers，我通常有一个HttpHandler Factory，它是唯一一个让它的“手”变脏并从容器中实例化HttpHandlers的类。
许多DI容器都有某种BuildUp方法来对已经实例化的对象执行setter注入。 如果您有服务位置，请尝试将其隔离到您的应用程序中，这纯粹是基础架构问题。 然后它将成为环境限制的缓冲领域。
简而言之，一些SL不会使您的努力失效，但要确保SL位是基础结构且包含良好。
以@ flq的答案为例提供一个例子。
我正在开发一个ASP.Net MVC项目，该项目大量使用Ninject。 有一些地方，我要么不能使用DI（扩展方法），要么它更干净，而不是使用SL（所有控制器的基类，构造函数注入会使控制器的所有构造函数变得混乱）。
所以，作为妥协，我使用轻微混合：
public interface IServiceLocator { T Create(); } public class NinjectServiceLocator : IServiceLocator { private readonly IKernel kernel; public NinjectServiceLocator(IKernel kernel) { this.kernel = kernel; } public T Create () { return kernel.Get (); } } public class ServiceLocator { private static IServiceLocator current; public static IServiceLocator Current { get { return current; } set { current = value; } } public T Create () { return current.Create (); } }
它可能不是最好的选择，或严格的SL模式，但它适用于我。 额外的界面让我可以换出定位器本身进行测试。 IKernel是Ninject的主要DI对象，它被配置，所以用你自己的框架代替，因为我遇到的大多数都有类似的核心。
这些情况下的典型方法是编写使用Service Locator的通用基础结构级包装器/适配器，但为使用此适配器的应用程序级类提供干净的IoC。
我这样做是为了在HttpModules和Providers中启用IoC，这两种情况下框架不允许控制实例化。 类似的方法可以用于其他类似的实体。
这里的要点是这样的包装器/适配器代码是可重用基础结构的一部分，而不是应用程序级代码。 通常不推荐的是在应用程序级代码中使用服务位置。
某些容器提供的“BuildUp”function对于这些限制来说是一个糟糕的解决方法。 BuildUp不允许您重新获得实例化的控制权，因此您将无法使用某些容器function，例如代理。