【问题标题】:Dynamic Configuration Roots? Based on db call?动态配置根?基于数据库调用?
【发布时间】:2018-03-13 18:21:31
【问题描述】:

我有一个应用程序在启动时知道足以选择数据库并提取配置对象。

然后它在那个配置对象上执行,处理一堆东西,拉另一个配置对象,在那个配置对象上执行,等等,在一个循环中。

现在,我在应用程序的开头有一个配置根,可以配置它可以配置的所有内容。但是由于它在 db 调用之后才知道所有内容,因此该点之后的所有对象分支都隐藏在工厂工厂的后面,因此它们可以处理配置对象中发生的任何配置。

我的问题是,这正常吗?似乎另一种选择是拥有两个配置根或两个 DI 容器。一个在 db 调用之前,一个在 db 调用之后。

如果我可以在调用 db 之后执行我的 DI root,我就可以将东西直接连接到那里的容器中,从而从我的代码中删除大量工厂,这些工厂之所以存在,是因为在应用程序启动时,我'不确定需要什么。但这似乎很奇怪。这也意味着我必须在每次迭代时重新创建我的容器或第二个容器,这看起来很奇怪。

编辑:我刚刚发现 StructureMap 有一个嵌套容器功能,几乎适用于这个确切的用例,所以我肯定会在这里做一些事情:http://structuremap.github.io/the-container/nested-containers/

编辑:我没有得到任何回复,但无论如何都能在以后回答这个问题。在下面添加了我的答案。

【问题讨论】:

    标签: dependency-injection architecture inversion-of-control ninject dependency-inversion


    【解决方案1】:

    所以事实证明这是一个相对常见的场景。

    第一步是认识到我的很多困惑来自于我的应用程序正在重构但还没有清晰的发布/订阅架构这一事实。

    一旦完成,很明显运行数据库前后的代码可以真正被视为单独的应用程序。

    那时,我基本上有两个选择。我可以将它们视为单独的应用程序,在这种情况下,它们每个都有自己独立的 di 根。

    或者,我可以继续在它们之间共享代码,并使用嵌套容器。

    显然,大多数 IoC(我检查了 Unity、StructureMap 和 WindsorCastle)都有方法可以将父容器/配置对象传递给子项目,并在该项目范围内让它克隆和覆盖特定注册。

    所以我的初始项目可以配置数据库和日志连接等,然后每个子项目实例都可以根据从数据库调用返回的任何数据扩展该共享配置实例。

    事实证明,我一直在使用的 IoC SimpleInjector 无法做到这一点。这是我困惑的一部分。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2016-11-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-10-08
      • 1970-01-01
      • 2016-05-24
      相关资源
      最近更新 更多