【问题标题】:Set scope of all bindings after loading a Ninject module加载 Ninject 模块后设置所有绑定的范围
【发布时间】:2015-03-12 01:33:52
【问题描述】:

我想通过将 Ninject 绑定分成 Ninject 模块来组织它们。但是,我有不止一个应用程序会使用这些模块。其中一个是 ASP.Net MVC 应用程序,另一个是控制台应用程序,另一个是 Windows 服务等。在 MVC 应用程序中,我想使用 InRequestScope 范围绑定,但在另一个应用程序中(引用Ninject 模块所在的核心程序集)我想使用不同的范围绑定。这可能吗?

随着我的基础设施的增长以及我所有绑定的注册变得非常庞大和冗长,我最终会在几个不同的组合根中重复这些绑定 - 它们之间的唯一区别是每个绑定的生命周期范围。我真的很想让这个更干燥。

理想的是以下(伪代码):

多个应用引用的核心组件

public class MyModule : NinjectModule {
    public override Load(){
        Kernel.Bind<IMyType>().To<MyType>();
    }
}

在 MVC 应用程序中

kernel.Load(new MyModule())
    .Configure(p => p.UseInRequestScope);

在另一个应用程序中

kernel.Load(new MyModule())
    .Configure(p => p.UseInTransientScope);

【问题讨论】:

    标签: c# dependency-injection ninject inversion-of-control


    【解决方案1】:

    composition root 用于编写应用程序。通过扩展,如果您有多个应用程序,则应该有尽可能多的组合根。

    它们是not meant for reuse,因为这会将应用程序紧密耦合在一起。正如帖子中指出的那样:

    尝试重用组合根比尝试“重用”应用程序没有意义。

    因此,简短的回答是为每个应用程序使用一个组合根,然后您可以根据需要以任何方式确定每个应用程序的关系范围。通过组合应用程序的组合根,您正在创建(至少)一个人为的问题,如果您将它们分开就不会存在。

    【讨论】:

    • 我了解,并且我已经阅读了那些文章。我也见过像this 这样的例子。随着我的基础设施的增长以及我所有绑定的注册变得非常庞大和冗长,我最终会在几个不同的组合根中重复这些绑定——它们之间的唯一区别是每个绑定的生命周期范围。你是说没有办法让它更干燥?
    • 使用 DI 的优点之一是能够创建基于约定的配置。许多 DI 容器允许您定义自己的约定。如果您将您的配置考虑为基于约定的,那么您将不会有很多重复的代码,实际上根本不会有太多的配置代码。 DRY 适用于文章中指出的单个应用程序。可以通过将一些代码移到模块中然后使用Visual Studio的链接文件功能来共享模块来作弊,但这意味着应用程序的测试和部署永远是耦合在一起的。
    • 另外,请记住,automate testing of a DI configuration 不可能真的。因此,如果共享配置,更改一个应用程序的配置可能会无意中破坏另一个应用程序的配置。在这种情况下,松散耦合在可维护性方面胜过 DRY。
    • 我不同意 NightOwl 的两个陈述。1) 虽然每个应用程序都有自己的组合根,但这并不意味着它们不能共享某些代码。以this answer 为例。 2) 自动化测试您的 DI 配置是可能的,甚至是可取的。这很好表达here
    猜你喜欢
    • 1970-01-01
    • 2023-04-09
    • 1970-01-01
    • 2017-12-04
    • 2018-11-25
    • 1970-01-01
    • 2015-02-20
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多