ASP.NET Core - 使用 [FromServices] 属性可能会带来哪些挑战或问题？ [关闭]

Question

我在 ASP Core MVC 中有一个控制器。我正在尝试减少构造函数中的依赖注入服务，以便我可以更轻松地开始构建单元测试。但是，我注入了一些仅用于一两个控制器操作的服务。例如，我注入ILocationService，因为在我的几个操作中，我需要查找一个国家Id 号码并使用数据库获取一个ISO Alpha-2 国家代码（例如将ID 号1 映射到“CA”，映射2 到“美国”等）

Asp Core 支持[FromServices] 属性，因此我可以选择将ILocationService 直接注入到我的两个操作中，而不是在控制器构造函数中注入它们。这样做的好处是我不需要总是从每个单元测试中模拟/注入ILocationService 到我的控制器中，并且在编写单元测试时更清楚每个函数所依赖的服务。

明显的缺点是它现在并不完全明显和清楚我的控制器所依赖的服务，因为它们并没有全部分组在构造函数中。

使用[FromServices] 属性可能会产生任何其他具体的挑战、问题或混淆点吗？

Answer 1

您应该考虑这种类型的method injection 有一些不幸的缺点：

• 这样的[FromServices] 属性很容易被遗忘，并且您只会在调用操作时发现（而不是在应用程序启动时 - 或在单元测试期间发现 - 您可以验证应用程序的配置）
• 出于性能原因需要从 constructor injection 移出，这表明注入的组件太重而无法创建，而 injection constructors should be simple 和组件创建因此应该非常轻量级。
• 需要摆脱构造函数注入以防止构造函数变得太大，这表明您的类具有太多依赖关系并且变得太复杂。换句话说，具有许多依赖项表明该类违反了Single Responsibility Principle。您的控制器操作可以很容易地拆分为不同的类这一事实证明这种控制器的内聚性不是很强，因此表明违反了 SRP。

因此，与其隐藏使用方法注入的根本问题，我建议在这里使用构造函数注入作为唯一的注入模式，并使您的控制器更小。然而，这可能意味着您的路由方案与您的类结构不同，但这完全没问题，并且完全受到 ASP.NET Core 的支持。

从可测试性的角度来看，顺便说一句，有时是否存在不需要的依赖关系并不重要。有effective test patterns 解决了这个问题。