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

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

3年前关闭。




Improve this question




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

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

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

使用 [FromServices] 是否有任何其他具体的挑战、问题或混淆点？属性？

Answer 1

这种类型的 method injection 有一些不幸的缺点。你应该考虑:

这样的[FromServices]属性很容易被遗忘，并且您只会在调用操作时发现(而不是在应用程序启动时发现 - 或在单元测试期间 - 您可以验证应用程序的配置)

需要远离constructor injection出于性能原因，表明注入(inject)的组件太重而无法创建，而 injection constructors should be simple ，因此，组件创建应该非常轻量级。

远离构造函数注入(inject)以防止构造函数变得太大的需要表明您的类具有太多的依赖关系并且变得太复杂。换句话说，具有许多依赖项表明该类违反了Single Responsibility Principle。 .您的 Controller 操作可以很容易地分成不同的类这一事实证明这种 Controller 不是很有凝聚力，因此表明违反了 SRP。

因此，与其隐藏使用方法注入(inject)的根本问题，我建议在这里使用构造函数注入(inject)作为唯一的注入(inject)模式，并使您的 Controller 更小。但是，这可能意味着您的路由方案与您的类结构不同，但这非常好，并且完全受 ASP.NET Core 支持。
从可测试性的角度来看，顺便说一句，有时是否存在不需要的依赖关系并不重要。有 effective test patterns解决这个问题。