c# - 解决方案中 Autofac 模块类的放置

Question

我一直在阅读大量有关 DI 和 autofac 的示例代码。我注意到的一件事是，许多人将接口(interface)和实现捆绑在同一个项目中。从设计的角度来看，我认为这是不正确的，所有接口(interface)都应该单独组装。所以我这样定义我的项目:

UI - Web 应用程序/Windows 应用程序/两者
- 意见
- 楷模
- Controller / View 模型
商业
- 服务/流程
- 接口(interface)
- 模型
数据存取
- 存储库和 UoW
- 接口(interface)
- 型号

这样，我的业务服务仅引用 DataAccess 接口(interface)和模型，而独立于实际实现。同样，UI也只指业务接口(interface)和模型，并且有明确的分离。这也有助于我在可以独立测试层的地方进行测试。

我的问题是关于 Autofac 模块声明。我需要设置我的构建以将实现复制到最终部署目录中。我的业务模块需要引用数据访问实现，UI需要访问业务模块。

1. 我应该如何处理模块中的这种依赖链？
2. 我应该在哪里放置模块类以及应该如何启动代码以最简单的方式发现所有模块？

我正在考虑 Autofac 的程序集扫描，但不确定那是否是唯一的选择。另请注意，我已经遵循命名约定，在大多数情况下，我不会编写单独的绑定(bind)。我在这里担心的是

1. 由于引用接口(interface)的项目不知道实现，我不能在调用程序集中编写任何特定绑定(bind)，例如 UI 根程序集。
2. 一些消息来源谈到保持程序集不包含任何 DI 实现，并为模块提供单独的程序集。这是否适用于所有类型的应用程序？ (例如企业 LOB 应用程序或 Web 应用程序与分发给许多独立用户的 ISV 桌面应用程序)

Answer 1

我的观点是，在单独的程序集中拥有接口(interface)和实现是过度的并且没有提供值(value)，因为您必须部署这两个程序集才能让您的项目正常工作。我喜欢引用this tweet来自 Paul Stovell，他指出 命名空间是关注单元，而程序集是部署单元。我发现这引起了我很大的共鸣。

回到您的问题:归根结底，您的可执行项目(Web 应用程序或 Windows 应用程序)需要了解接口(interface)和实现。
我的意见是 Autofac 模块应该位于顶层项目中，因此它应该引用所有必要的项目。我的理由是，除了定义服务注册之外，您还需要为每个服务定义生命周期。该概念取决于使用您的依赖项的项目； Web 项目可能会根据 HTTP 请求注册一些服务，而 Windows 应用程序可能具有不同的生命周期。

对我来说，模块非常适合将注册分组在一起，但这并不意味着它们需要与其包含注册的服务存在于同一个项目中。