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

Question

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

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

现在我的项目结构在visual studio中有一个解决方案：

项目A：用户界面

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

项目C：线程管理器API

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

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

现在我将陈述我对国际奥委会的理解： DIP表示高级模块不应该依赖于低级模块，高级和低级模块都应该依赖于抽象。如果要在更改低级模块时阻止高级模块的更改，则需要反转控件，以便低级模块不会控制接口并创建高级模块所需的对象。

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

Answer 1

考虑您的方案的以下示例项目组织：

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

项目B：用户界面（或模块化所需的项目数量）。 知道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项目是唯一具有全局图的项目，其余应该只使用由引导程序设置的容器将为它们解析（即注入）的接口。

Answer 2

  

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

没有。您应该替换术语“模块”＆＃39;与＆＃39; class＆＃39;。在这种情况下，它开始变得更有意义：

  

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

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

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