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

Question

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

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

现在我的项目结构在视觉工作室的一个解决方案下：

项目A：用户界面

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

项目C：线程管理器API

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

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

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

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

Answer 1

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

不可以。你应该用“类”代替“模块”。在这种情况下，它开始变得更有意义：

高级[class]不应该依赖于低级[class]，高级和低级[class]都应该依赖于抽象。

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

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

Answer 2

考虑下面的示例项目组织：

项目甲：引导器，负责运行应用程序，配置DI和设置用户界面（这也可以放在一个与应用程序和用户界面分离的专用引导器项目中）。知道B，C，D，E，F

项目B：用户界面（或使其模块化所需的尽可能多的项目）。知道C

项目C：业务逻辑（从第三方服务获取数据，并进行反序列化和一些线程管理工作）。知道D

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

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

项目F：线程管理器API知道D

注意到通过业务逻辑层与用户界面和实现的解耦。这样，您可以切换实现细节，而不必更改业务逻辑或用户界面。此外，如果您的业务逻辑发生变化，影响将最小化。

关于DI，bootstrapper项目是唯一一个完整的项目，其他项目应该只使用bootstrapper设置的容器将为它们解析（即注入）的接口。