通过接口和项目结构进行依赖注入答案

【问题标题】：Dependency Injection through Interface and project structure通过接口和项目结构进行依赖注入
【发布时间】：2014-02-12 14:58:48
【问题描述】：

这个问题有点难解释，但我会尽力而为。

我有一个项目，我必须制作一个从第三方服务获取数据并进行反序列化和一些线程管理工作的 UI。

现在我的项目结构在 Visual Studio 中的一个解决方案下：

项目 A：用户界面

Project B：从第三方服务获取数据的 API

项目 C：线程管理器 API

注意：项目B有IB接口，C有IC接口帮助依赖注入。项目 B 和 C 将来会被其他团队使用。

项目 A 使用 IB 和 IC 接口进行依赖注入。

现在我将陈述我对国际奥委会的理解： DIP 表示高级模块不应该依赖于低级模块，高级模块和低级模块都应该依赖于抽象。如果要防止高层模块在低层模块发生变化时发生变化，则需要反转控制，使低层模块不会控制高层模块需要的接口和对象的创建。

根据上面的定义IB和IC接口都应该在项目A中定义吧？如果他们在项目 A 中，那么其他团队将如何使用 IB 和 IC 接口？我是否要创建另一个单独的项目来存储接口？

【问题讨论】：

【解决方案1】：

为您的场景考虑以下示例项目组织：

项目 A：Bootstrapper，负责运行应用程序、配置 DI 和设置 UI（这也可以放在与应用程序和 UI 分离的专用 Bootstrapper 项目中）。 知道 B、C、D、E、F

项目 B：UI（或使其模块化所需的多个项目）。 懂 C

项目 C：业务逻辑 (gets data from a third party service and does deserialization and some thread management work)。 知道 D

项目 D：接口，包含 IB 和 IC（它们也可以有单独的专用项目）。

项目 E：The API to get data from third party service 知道 D

项目 F：The Thread Manager API 知道 D

注意与 UI 的解耦以及通过业务逻辑层的实现。这样，您可以切换实现细节，而无需更改业务逻辑或 UI。此外，如果您的业务逻辑发生变化，则影响最小化。

关于 DI，bootstrapper 项目是唯一拥有全貌的项目，其余的应该只使用由 bootstrapper 设置的容器将为它们解析（即注入）的接口。

【讨论】：

什么是 BI 和 CI .. 你的意思是 IB 和 IC 吗？如果是，那么我们有一个单独的项目来定义接口？
@Debdeep 抱歉，这是一个错字：是的，他们会进入一个单独的项目，这样您就可以将他们的具体实现与使用它们的其他项目（例如项目 C）分开。
实际上我不需要单独的项目C和E，它们在C内部，因为C获取数据并为我反序列化（不需要业务逻辑）。但我需要将项目 C 和 F 作为 dll 提供给其他团队。那么我是否需要将项目 D 也作为单独的 dll 提供？
@Debdeep 业务逻辑可以像“使用 E 中实现的接口获取数据并序列化，同时通过 F 中实现的接口使用线程管理器”一样简单。无论如何，如果您的其他团队需要使用这些实现，是的，他们将需要 .dll

【解决方案2】：

根据上述定义，IB 和 IC 接口都应该是在项目A中定义的吧？

没有。您应该将术语“模块”替换为“类”。在这种情况下，它开始变得更有意义：

高级 [class] 不应依赖于低级 [class] 和两者高级和低级 [类] 应该依赖于抽象。

为了能够正确地进行依赖注入，这些类和抽象位于哪个程序集中并不重要。当项目变得更大时（即数百万行代码，一个或多个团队在处理它），遵守Principles of Component Design 变得很重要。

在您的情况下，由于程序集 A 和 B 都使用接口 IB，并且程序集 A 依赖于程序集 B，因此 IB 永远不能位于程序集 A 中，因为这会导致程序集中的循环引用。您必须将 IB 放置在程序集 B 中或 A 和 B 都引用的新程序集中。

【讨论】：