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

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

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

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

使用该工具可能会出现任何其他具体挑战、问题或困惑点吗？[FromServices]属性？

这种类型有一些不幸的缺点方法注入 https://freecontent.manning.com/understanding-method-injection/您应该考虑：

• Such [FromServices]属性很容易被忘记，并且您只会在调用操作时找到（而不是在应用程序启动时找到 - 或在单元测试期间 - 您可以在其中验证应用程序的配置）
• 搬家的必要性构造函数注入 https://freecontent.manning.com/understanding-constructor-injection/出于性能原因，这表明注入的组件太重而无法创建，而注入构造函数应该很简单 https://blog.ploeh.dk/2011/03/03/InjectionConstructorsshouldbesimple/，因此，组件创建应该非常轻量级。
• 需要远离构造函数注入以防止构造函数变得太大，这表明您的类有太多依赖项并且变得太复杂。换句话说，具有许多依赖关系表明该类违反了单一责任原则 https://en.wikipedia.org/wiki/Single_responsibility_principle。您的控制器操作可以轻松地划分为不同的类，这一事实证明此类控制器的内聚性不是很强，因此表明存在 SRP 违规。

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

顺便说一句，从可测试性的角度来看，如果有时存在不需要的依赖项，那并不重要。有有效的测试模式 https://stackoverflow.com/a/32595171/264697解决这个问题。