7

我正在使用这个 ninject 绑定：

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

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

这种实现有什么缺点，还是有更好的方法来实现他的环境上下文？对于每个请求，都会创建用户对象——如果它是匿名用户也是如此。

4

1 回答 1

6

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

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

[更新] 由于这个和其他原因，.NET 第二版中的依赖注入一书将环境上下文称为反模式。

这一切都可以通过在构造函数中注入所有依赖项来简单地克服。或者让我们从不同的角度来看待它。如果你的类依赖于这个服务，为什么不注入到构造函数中呢？

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

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

kernel.Bind<RolePrincipal>()
    .ToMethod(c => (RolePrincipal)HttpContext.Current.User);
于 2012-10-22T10:18:00.770 回答