设计原则之显式依赖关系

我们都知道依赖注入的方式常见的主要有三种

1. 构造函数注入
2. 属性注入
3. 接口注入

在大名鼎鼎的Spring框架中大量使用属性注入的方式，属性注入的方式写起来那是真的爽；而在Asp.NetCore中则不支持属性注入，如果不使用第三方库，我们就只能在构造函数上写上一堆参数，比较麻烦，有些人是非常讨厌这种注入方式，选择使用第三方IOC框架。

Asp.Net Core框架哪哪都牛逼，可偏偏不支持很多人崇尚的属性注入呢？如果你还在期待什么时候支持这一特性，可能会让你失望了。但也不排除社区呼声很高的情况下支持这个特性。但这属性注入它不是推荐的方式。

方法和类应显式要求正常工作所需的任何协作对象。 我将此称为显式依赖关系原则。通过类构造函数，类可以标识其实现有效状态和正常工作所需的内容。 如果定义的类可供构造和调用，但仅在具备特定全局组件或基础结构组件时正常工作，则这些类对其客户端而言就不诚实。 构造函数协定将告知客户端，它只需要指定的内容（如果类只使用无参数构造函数，则可能不需要任何内容），但随后在运行时，结果发现对象确实需要某些其他内容。

若遵循显式依赖关系原则，类和方法就会诚实地告知客户端其需要哪些内容才能工作。 遵循此原则可以让代码更好地自我记录，并让代码协定更有利于用户，因为用户相信只要他们以方法或构造函数参数的形式提供所需的内容，他们使用的对象在运行时就能正常工作。

如果你你赞成这一设计原则，那就不要折腾地去实现属性注入了，不仅仅是在依赖注入这一场景，在其他时候我们应该遵循这一原则地初衷，请尽量把你方法或类中依赖的对象大大方方的显示声明出来。

您怎么看待这个问题？

引用：

1. https://docs.microsoft.com/zh-cn/dotnet/architecture/modern-web-apps-azure/architectural-principles#explicit-dependencies