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

在经过多次踢和尖叫之后,我开始接受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上下文.”这混淆了两者的定义,并且不允许针对同一问题的不同解决方案.

我们所缺少的是对我们正在解决的问题的明确阐述.对于这个例子,它将是这样的：

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);
    }
}