保持 .NET 依赖注入有序答案

【问题标题】：Keeping .NET Dependency Injection in Order保持 .NET 依赖注入有序
【发布时间】：2019-04-26 07:22:20
【问题描述】：

最近我开始使用 .NET Core 2.1 开发一个新项目，我决定使用 SOLID 原则并创建一个不错的项目结构。

这是一个 Web API 项目。一切正常我使用了很多依赖注入，大部分东西都很容易测试。

这就是我必须注册所有服务的部分。我实际上有数百行看起来像这样：

services.AddSingleton<...>();

或

services.AddScoped<...>();

我的每项服务都有一条线路，对于一个小项目来说就可以了。然而，当我有数百个这样的东西时，它变得一团糟。基本上，整个项目的秩序非常好，而且 Startup.cs 中充满了 services.AddX 语句。

我曾考虑使用注册服务的方法创建静态类，但这看起来不太好。

将来我需要添加更多服务，我不能只是继续创建静态类或填充旧类，因为我最终会再次陷入同样的混乱，而且我更难以记住我在哪里注册给定的服务。

【问题讨论】：

我很感兴趣为什么你有数百个。这似乎是一个巨大的项目，或者是一个设计问题。
假设您确实需要它们并且不能将项目分开，您可以使用反射根据类的名称、属性或它们实现的接口来查找要注册的类。这就是像Autofac 这样更高级的 IoC 容器的工作方式。你可以integrate Autofac with ASP.NET Core 或者你可以实现类似的技术
您可以让每组服务（组装）导出自己的 RegisterServices 方法。对于花哨的化妆品，使其成为Microsoft.Extensions.DependencyInjection 命名空间中的AddMyStuff() 扩展方法。有关示例，请参阅 AddMvc()。
数百不是很多。至少不适用于 DI 容器。
但是当我有数百个这样的时候，它就会变得一团糟 - 它不应该是一团糟，因为你将拥有一个执行数百个简单、清晰的函数和易于理解的代码行。

【解决方案1】：

如果你真的有数百个，你可能想用 Autofac 替换默认容器。这些类型的框架支持模块或某种“子容器”。

模块是一个小类，可用于在“外观”后面捆绑一组相关组件，以简化配置和部署。

【讨论】：

您是否知道迁移到 Autofac 的过程是否可以轻松完成，或者我应该从一开始就开始使用它？
也许看看这个。stackoverflow.com/questions/42809618/… 我在 wcf 项目中使用了 autofac，但在 .net core 中我没有遇到默认容器的问题。

【解决方案2】：

您可以让每个逻辑服务组（组装）导出自己的 RegisterServices 方法。无论如何选择生命周期和范围是该程序集的责任。

对于化妆品，使其成为Microsoft.Extensions.DependencyInjection 命名空间中的AddMyStuff() 扩展方法。

有关示例，请参阅 AddMvc()。查找 (F12) 并注意程序集和它所在的命名空间之间的区别。

【讨论】：