用Ninject注入当前用户 - 有什么缺点吗？

Question

我正在使用这个Ninject绑定：

kernel.Bind<ICurrentUser>().To<CurrentUser>()
    .InRequestScope()
    .WithConstructorArgument("principal", 
        context => (RolePrincipal HttpContext.Current.User);

在服务层的一个装饰器中，我只需将“ICurrentUser currentUser”添加到构造函数中即可获得该对象并使其运行。

这种实现方式有什么不利之处，或者是否有更好的实现环境上下文的方法？对于每个请求，用户对象都会被创建-即使是匿名用户。

- Vindberg

Answer 1

使用环境上下文(Ambient Context)的情况非常有限，而使用构造函数注入通常会产生最佳结果。

例如，考虑使用环境上下文如何使单元测试变得复杂。使用环境上下文通常意味着您需要更改测试设置中的上下文并在测试拆卸时将其删除。但是，单元测试框架通常在多个线程上运行一组测试（例如MSTest），当您使用这样的静态变量时，这意味着您的测试互相影响。

[更新]由于此原因和其他原因，《依赖注入在.NET中的应用(第二版)》将环境上下文称为反模式。

所有这些都可以通过在构造函数中注入所有依赖项来简单地解决。或者从不同的角度来看待这个问题。如果您的类依赖于此服务，为什么不将其注入到构造函数中呢？

唯一让我担心的是显式构造函数参数注册。这使得您的配置更加脆弱。由于您的CurrentUser依赖于RolePrincipal，因此这样注册是合理的：

kernel.Bind<ICurrentUser>().To<CurrentUser>().InRequestScope();

kernel.Bind<RolePrincipal>()
    .ToMethod(c => (RolePrincipal)HttpContext.Current.User);

- Steven

---

谢谢Steven，我明白了。我会将其更改为方法注入。 - Vindberg

我在这里挑刺，方法注入是指将依赖项注入到方法中。ToMethod方法允许您定义一个（工厂）委托来将依赖项注入到构造函数中。 - Steven

是的，我从Ninject文档中得到了那个信息，但还是谢谢你的指正 :) - Vindberg