c# – 以这种方式用Ninject注入当前用户 – 任何缺点?

前端之家收集整理的这篇文章主要介绍了c# – 以这种方式用Ninject注入当前用户 – 任何缺点?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在使用这个ninject绑定:
kernel.Bind<ICurrentUser>().To<CurrentUser>()
    .InRequestScope()
    .WithConstructorArgument("principal",context => (RolePrincipal HttpContext.Current.User);

在我的服务层的一个装饰器中,我只需将“ICurrentUser currentUser”添加到构造函数中以获取对象及其工作.

这种实现是否存在任何缺点,或者是否有更好的方法来实现其环境上下文?对于每个请求,都会创建用户对象 – 如果是匿名用户也是如此.

解决方法

环境上下文的使用非常有限,使用构造函数注入通常会产生最佳结果.

例如,考虑使用环境上下文如何使单元测试复杂化.使用环境上下文通常意味着您需要在测试设置中更改该上下文并在测试拆卸中将其删除.但是单元测试框架通常在多个线程上运行一组测试(例如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);

猜你在找的C#相关文章