【问题标题】:Injecting Current User with Ninject this way - any disadvantages?以这种方式用 Ninject 注入当前用户 - 有什么缺点吗?
【发布时间】:2012-10-22 09:57:11
【问题描述】:

我正在使用这个 ninject 绑定:

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

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

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

【问题讨论】:

    标签: c# asp.net-mvc dependency-injection ninject


    【解决方案1】:

    Ambient Context 的使用非常有限,使用构造函数注入通常会产生最好的结果。

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

    [更新] 因为这个和其他原因,本书Dependency Injection in .NET, Second Edition​​环境上下文为反模式。

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

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

    kernel.Bind<ICurrentUser>().To<CurrentUser>().InRequestScope();
    
    kernel.Bind<RolePrincipal>()
        .ToMethod(c => (RolePrincipal)HttpContext.Current.User);
    

    【讨论】:

    • 谢谢史蒂文,这是有道理的。我将其更改为方法注入。
    • 我在这里吹毛求疵,但方法注入是指您将依赖项注入一个方法。 ToMethod 方法允许您定义一个(工厂)委托以将依赖项注入 构造函数
    • 是的,我是从 Ninject 文档中得到的,但感谢您的挑剔:)
    猜你喜欢
    • 2014-01-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-07-20
    • 2017-01-03
    • 1970-01-01
    • 2021-09-24
    相关资源
    最近更新 更多