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

Question

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

但是,对于DI来说,IMO仍然是一个显着的阻碍:

当您无法控制对象的实例化时,DI是不可能的.在ASP.NET世界中,示例包括:HttpModule,HttpHandler,Page等.

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

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

Answer 1

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

例如,如果我们想要当前的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);
    }
}