c# - 将 IoC 与内部对象一起使用

Question

我目前正在为我使用的程序编写一个开源 SDK，并且我在内部使用 IoC 容器（NInject）来连接我所有的内部依赖项。

我有一些标记为内部的对象，这样我就不会拥挤公共 API，因为它们仅在内部使用并且不应该被用户看到，比如工厂和其他对象。我遇到的问题是 NInject 无法创建内部对象，这意味着我必须将所有内部对象标记为公共，这会挤满公共 API。

我的问题是：有什么办法可以解决这个问题还是我做错了？

PS。我曾考虑过使用 InternalsVisiableTo 属性，但我觉得这有点异味。

score 3 · Accepted Answer

快速查看其他答案：看起来您所做的事情并没有如此不同，以至于 Ninject 存在根本性错误，您需要对其进行修改或替换。在许多情况下，您不能“直接使用 [the] internals”，因为它们依赖于未解决的依赖注入；因此首先使用了 Ninject。此外，听起来您已经拥有一组内部接口，这就是提出问题的原因。

想法：直接在你的 SDK 或库中使用 Ninject 的一个问题是你的用户将不得不在他们的代码中使用 Ninject。这对你来说可能不是问题，因为它是你的 IoC 选择，所以无论如何你都会使用它。如果他们想使用另一个 IoC 容器怎么办，那么现在他们实际上有两个正在运行的复制工作。更糟糕的是，如果他们想使用 Ninject v2 而您使用的是 v1.5，那么情况就会变得更加复杂。

最好的情况：如果您可以重构您的类，以便它们通过依赖注入获得所需的一切，那么这是最干净的，因为库代码不需要任何IoC 容器。该应用程序可以连接依赖项并且它只是流动。但这并不总是可能的，因为有时库类需要创建具有无法通过注入解决的依赖关系的实例。

建议：CommonServiceLocator（和它的 Ninject 适配器）是专门为这种情况设计的（具有依赖关系的库）。您针对 CommonServiceLocator 进行编码，然后应用程序指定哪个 DI/IoC 实际支持该接口。

现在您的应用程序中必须有 Ninject和CommonServiceLocator有点痛苦，但 CommonServiceLocator 非常轻量级。您的 SDK/库代码仅使用相当干净的 CommonServiceLocator。

score 0 · Accepted Answer

我猜你甚至不需要那个。IoC 是针对公共事物的。直接进入内部。

但是——这只是我的直觉……

score 0 · Accepted Answer

0

创建一个不同于外部 API 的辅助内部 API。您可能需要手动进行拆分...

于 2009-06-23T00:07:01.887 回答

score 0 · Accepted Answer

我将投票支持 InternalsVisibleTo 解决方案。完全没有气味，真的。该属性的重点是启用您想要的那种行为，因此与其跳过各种复杂的圈子让事情在没有它的情况下工作，只需使用框架提供的功能来解决这个特定问题。

我还建议，如果您想对用户隐藏您选择的容器，请使用ILMerge将 Ninject 程序集与您的 SDK 程序集结合起来，并应用/internalize参数将 Ninject 程序集的可见性更改为内部，因此 Ninject命名空间不会从您的库中泄漏（抱歉，无法在线找到指向 ILMerge 文档的链接，但下载中有一个 doc 文件）。还有一篇关于将 ILMerge 集成到构建过程中的不错的博客文章。

score -2 · Accepted Answer

-2

你可以

修改忍者
选择一个不同的容器

于 2009-06-23T00:14:31.123 回答

c# - 将 IoC 与内部对象一起使用

5 回答 5

Related

Reference