我开始以不同的方式看待 Dependency Injection 😊🍺

Source: Dev.to

依赖注入 (DI)：它不仅仅是为了写出干净的代码——更是为了降低服务器成本

许多开发者把依赖注入 (DI) 看作一种让代码“更好看”的高级架构概念。对我而言，任何高级技术的最终目标都很简单：让服务器在保持低开销的同时能够承受更大的负载。DI 正是为此而生的秘密武器。

1. 请求的解剖：“对象簇”

处理一次请求时，应用会创建一个相互链接的“对象簇”：

• Controller – 请求的入口点。
• Services – 包含业务逻辑。
• Repositories、Logging 和 Database Contexts – 负责数据访问和诊断。

这正是面向对象编程的核心：把一切都转化为对象来处理。任务完成后，这个簇会被销毁。

2. RAM 噩梦与 DI 的诞生

DI 的出现是为了解决对象簇对内存的高消耗。虽然它被 Martin Fowler、Robert C. Martin（Uncle Bob）等业界大咖广为宣传，但在 .NET 世界里，它已经成为调控这些对象生命周期的“心脏”。

3. “生死”协调者：Singleton、Scoped 与 Transient

• Transient（短暂） – 每次请求时都会创建一次。可以把它想象成一次性纸巾——用完即丢。适用于轻量、无状态的逻辑。
• Scoped（请求范围） – 在单个 HttpContext 的整个对象簇中共享同一个实例。请求结束后，它的角色也随之结束。这大幅节省 RAM，因为我们不必在同一线程内多次创建相同的服务。
• Singleton（长期） – 应用启动时创建一次，直至关闭才销毁。它是被数百万请求共享的“大老板”。是终极的资源节约手段，但需要谨慎处理数据并发问题。

4. 另一面的硬币：解耦

感谢阅读我对 DI 的看法。这是我第一次写这类内容，如果你有不同的观点或发现任何缺漏，欢迎在评论区告诉我！让我们一起分享、共同学习。 🍻