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

Question

这个问题有点难以解释，但我会尽我所能。

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

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

项目A: UI

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

项目C:线程管理器API

注意:项目B有一个IB接口，C有一个IC接口来帮助依赖注入。项目B和C今后将供其他小组使用。

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

现在我要说明我对国际奥委会的理解: DIP说，高级别模块不应该依赖于低级别模块，高级别和低级别模块都应该依赖抽象。如果您想要防止高层模块在更改低级别模块时发生的更改，则需要反转控件，以便低级别模块不会控制高级模块所需的接口和对象的创建。

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

Answer 1

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

项目A:引导程序，负责运行应用程序、配置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项目是唯一具有全貌的项目，其余的应该只使用引导程序设置的容器为它们解析(即注入)的接口。

Answer 2

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

不是的。您应该将“模块”一词改为“类”。在这种情况下，它开始变得更有意义：

高级类不应该依赖于低级类，高级类和低级类都应该依赖抽象。

为了能够正确地进行依赖注入，这些类和抽象位于哪个程序集中并不重要。当项目变得更大(即数百万行代码、一个或多个团队正在处理它)时，坚持构件设计原理就变得非常重要。

在您的示例中，由于程序集A和B都使用接口IB，而程序集A依赖于程序集B，因此IB永远不能位于程序集A中，因为这将在程序集中使用循环引用。您必须将IB放在程序集B中，或者放在A和B都引用的新程序集中。