fastapi-依赖注入

如何用最简单的方式解释依赖注入？依赖注入是如何实现解耦的?
FastApi学习-06
fastapi（十六）-依赖关系
fastapi教程-进阶九（Dependencies-1）

什么是依赖注入

依赖注入听起来好像很复杂，但是实际上炒鸡简单，一句话说就是：本来我接受各种参数来构造一个对象，现在只接受一个参数——已经实例化的对象。
也就是说我对对象的『依赖』是注入进来的，而和它的构造方式解耦了。构造它这个『控制』操作也交给了第三方，也就是控制反转。
不举抽象的什么造汽车或者小明玩儿手机的例子了。一个很实际的例子，比如我们要用 redis 实现一个远程列表。耦合成一坨的代码可以是这样写，其中我们需要自己构造需要用的组件：

class RedisList:
    def __init__(self, host, port, password):
        self._client = redis.Redis(host, port, password)

    def push(self, key, val):
        self._client.lpush(key, val)

l = RedisList(host, port, password)

依赖翻转之后是这样的：

class RedisList:
    def __init__(self, redis_client)
        self._client = redis_client

    def push(self, key, val):
        self._client.lpush(key, val)

redis_client = get_redis_client(...)
l = RedisList(redis_client)

看起来好像也没什么区别，但是考虑下面这些因素：

• 线下线上环境可能不一样，get_redis_client 函数在线上可能要做不少操作来读取到对应的配置，可能并不是不是一个简单的函数。
• redis 这个类是一个基础组件，可能好多类都需要用到，每个类都去自己实例化吗？如果需要修改的话，每个类都要改。
• 我们想依赖的是 redis 的 lpush 方法，而不是他的构造函数。

所以把 redis 这个类的实例化由一个单一的函数来做是有意义的。

fastapi中的依赖注入

对于类A,要是实现A的功能，必须要类B的功能。所以在A中实例化一个B。一旦B需要重构，由于A几乎完全依赖与B,所以A几乎也要重构。这是一种相当耦合的模式，依赖注入就是为了解决这种耦合性。
A不再new一个B的实例，而是让B的一个实例作为A的一个成员存在，A不再关注B的实例化，只关注B的方法。（这是我的理解，也许有不对的地方）

在FastApi的框架中，依赖注入用于解决重复的逻辑代码，分享数据库的链接，统一验权等功能。旨在减少代码重复。

async def pagination(page_num: int = 1, page_count: int = 10):
    return {"page_num": page_num, "page_count": page_count}
 
@app.get("/request01")
async def request01(*, page: dict = Depends(pagination), c: int):
    return [page, c]

使用Depends实现依赖注入，pagination方法接收的page_num当前页码数，page_count每页的数据量，经过处理后返回给page一个起始结束下标的范围字典。在这个例子中来看，和其实现的功能和装饰器有点像，对于request01,不关注我接受了什么数据，只希望获取分页的下标范围，而pagination方法实现了该功能，这样当分页的数据格式发生变更时，也只需要改变pagination方法。