我正在使用这个ninject bind:
kernel.Bind<ICurrentUser>().To<CurrentUser>()
.InRequestScope()
.WithConstructorArgument("principal",
context => (RolePrincipal HttpContext.Current.User);
在我的服务层的一个装饰器中,我只是将“ICurrentUser currentUser”添加到构造函数中以获取对象及其工作。
此实现是否存在任何缺点,或者是否有更好的方法来实现其环境上下文?对于每个请求,都会创建用户对象 - 即使是匿名用户也是如此。
答案 0 :(得分:6)
Ambient Context 的使用非常有限,使用构造函数注入通常会产生最佳结果。
例如,考虑如何使用 Ambient Context 使单元测试复杂化。使用环境上下文通常意味着您需要在测试设置中更改该上下文并在测试拆卸中将其删除。但是单元测试框架通常在多个线程上运行一组测试(例如MSTest),当你使用这样的静态变量时,这意味着你的测试会相互影响。
[更新]由于这个原因和其他原因,本书Dependency Injection in .NET, Second Edition将 Ambient Context 称为反模式。
通过在构造函数中注入所有依赖项,可以简单地克服这一切。或者让我们从不同的角度来看待它。如果你的类依赖于这个服务,为什么不注入构造函数?
唯一令我担心的是显式构造函数参数注册。这使您的配置更加脆弱。由于您的CurrentUser
取决于RolePrincipal
,因此可以直接注册它:
kernel.Bind<ICurrentUser>().To<CurrentUser>().InRequestScope();
kernel.Bind<RolePrincipal>()
.ToMethod(c => (RolePrincipal)HttpContext.Current.User);