但是,对于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上下文.”这混淆了两者的定义,并且不允许针对同一问题的不同解决方案.
我们所缺少的是对我们正在解决的问题的明确阐述.对于这个例子,它将是这样的：
Determine the user which made the current request
我们使用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);
}
}
