在解决方案中放置Autofac Module类

Question

我已经阅读了很多关于DI和autofac的示例代码。我注意到的一件事是，许多人在同一项目中捆绑了接口和实现。从设计的角度来看，我认为这是不正确的，所有接口都应单独组装。所以我这样定义我的项目：

UI - Web App/Windows App/Both - Views - Models - Controllers/ ViewModels Business - Services/Processes - Interfaces - Model DataAccess - Repositories & UoW - Interfaces - Model

这样，我的业务服务仅引用DataAccess接口和模型，而与实际实现无关。同样，UI也仅指业务接口和模型，并且存在明显的分离。这也有助于我测试可以独立测试图层的地方。

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

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

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

1. 由于引用项目的接口不了解实现，因此我无法在调用程序集（如UI根程序集）中编写任何特定的绑定。
2. 一些消息来源谈到要保持程序集不受任何DI实现的影响，并具有用于模块的单独程序集。对于所有类型的应用程序，这都是一种好方法吗？ （例如，分发给许多独立用户的企业LOB应用或Web应用与ISV桌面应用）

Answer 1

我的观点是，在单独的程序集中具有接口和实现会超出它的范围，并且无法提供价值，因为您必须部署两个程序集才能使项目正常工作。我喜欢参考Paul Stovell的this tweet，他指出命名空间是关注的单元，而程序集是部署的单元。我发现这引起了我的共鸣。

回到您的问题：最终，您的可执行项目（Web应用程序或Windows应用程序）需要知道接口和实现。
我的意见是Autofac模块应该存在于顶层项目中，因此应该引用所有必要的项目。我这样做的理由是，除了定义服务注册之外，您还将定义每个服务的生存期。这个概念取决于使用您的依赖项的项目。一个Web项目可能每个HTTP请求都会注册一些服务，而Windows应用程序的生存期可能会有所不同。

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