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上下文.”这混淆了两者的定义,并且不允许针对同一问题的不同解决方案. 我们所缺少的是对我们正在解决的问题的明确阐述.对于这个例子,它将是这样的:
我们使用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); } } (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |