【问题标题】:Dependency Injection Container for each Class Library每个类库的依赖注入容器
【发布时间】:2017-10-13 00:24:58
【问题描述】:

所以,这是我第一次与 DI 打交道,如果我误解了整个 DI 的事情,请纠正我。

这些是我的几个项目:

  1. Web 应用程序/Web API 项目 - 取决于服务类 + 注入 Automapper(配置仅适用于当前项目)
  2. 服务(类库) - 取决于数据类 + 注入 Automapper(配置仅适用于当前项目)
  3. 数据(类库)

我的目的是让每个项目都有自己的 DI 容器(Unity DI 说)。我不确定每个项目都可以有自己的 DI 容器。

我已经阅读了一些文章,表明它无法完成(不确定我是否正确解释它们)但我不确定为什么?

如果它不能完成,任何人都可以解释它,我该如何实现这一点,我不想在应用层 DI 的数据层中注册类。

如果每个项目都可以有自己的DI,那么在将IMapper注册为实例时会覆盖其他层的IMapper吗?

【问题讨论】:

    标签: c# dependency-injection automapper unity-container


    【解决方案1】:

    我的目的是让每个项目都有自己的 DI 容器(Unity DI 说)。我不确定每个项目都可以有自己的 DI 容器。

    正如here 解释的那样,您应该组合所有对象图:

    尽可能靠近应用程序的入口点。

    这个地方叫做Composition Root

    组合根是应用程序中的(最好)唯一位置,模块组合在一起。

    换句话说,您应该使用 DI 容器并配置应用程序依赖项的唯一位置是在启动项目中。所有其他项目都应该忽略容器,并且应该完全应用 构造函数注入

    看了一些文章,显示做不到

    可以,但不应该。

    如果每个项目都可以有自己的DI,那么在注册IMapper为实例时会覆盖其他层的IMapper吗?

    如果您应用 Composition Root 模式,这个问题就会消失。在 Composition Root 中,您可以完全控制哪个组件获取哪个依赖项。

    专业提示:阅读this book

    【讨论】:

    • 这是否意味着 service.dll 的每个使用者都需要具有复合根才能包含依赖项?如果我需要将此 dll 公开怎么办?
    • @Leonz:如果您创建可重用库,thisthis 建议适用。
    • "这是否意味着 service.dll 的每个使用者都需要具有复合根才能包含依赖项?"只有启动项目才有复合根,通常复合根是not reused
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-04-30
    • 1970-01-01
    • 2012-02-02
    • 2014-09-15
    • 1970-01-01
    • 2016-11-13
    相关资源
    最近更新 更多