设计原则中如何体现显式依赖关系？

本文共计812个文字，预计阅读时间需要4分钟。

前言：我们都知道依赖注入的方式通常有三种：构造函数注入、属性注入和接口注入。在大名鼎鼎的Spring框架中，大量使用属性注入的方式，而属性注入的写法确实是爽；而在A中，却是另外一番景象。

前言

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

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

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

思考一个问题

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

显式依赖关系

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