关于ASP.NET Core MVC中依赖注入抽象优势的困惑

你对DI抽象隔离的理解确实偏了点——DI的核心价值不是帮你规避抽象契约的变更，而是实现具体实现类与消费类的解耦。

先理清核心逻辑 #

DI的抽象层（接口/抽象类）是用来定义消费类和实现类之间的契约的。消费类只依赖这个契约，不直接依赖具体的实现类。当你修改WriteMessage的参数时，本质是修改了这个契约的内容，这时候不管用不用DI，所有依赖这个契约的消费类都得跟着调整——因为契约变了，大家都得遵守新规则。

DI的抽象隔离优势体现在这些场景 #

• 替换实现类无需修改消费类
  假设你定义了IMyDependency接口，里面有void WriteMessage(string message)方法，MyDependency是它的一个实现。消费类（比如HomeController）通过构造函数注入IMyDependency来使用。
  现在你要换一个实现MyDependencyV2（同样实现IMyDependency，WriteMessage参数不变，但内部改成写入数据库而不是控制台），只需要在DI容器注册时把services.AddScoped<IMyDependency, MyDependency>()改成services.AddScoped<IMyDependency, MyDependencyV2>()，所有消费类不用改一行代码，就能自动用上新的实现。
  要是不用DI，你得在所有new MyDependency()的地方改成new MyDependencyV2()，工作量大还容易漏。

• 单元测试更便捷
  写单元测试时，你可以给消费类注入一个Mock的IMyDependency实现，比如让WriteMessage不做实际操作，只记录调用次数或者参数。不用DI的话，消费类直接耦合MyDependency，你要么改消费类代码，要么很难模拟它的行为，测试起来麻烦得多。

总结 #

你遇到的情况是修改了抽象契约（方法签名），这属于API层面的变更，DI解决不了这个问题。但DI能帮你把消费类和具体实现彻底分开，让你在不破坏契约的前提下，自由替换实现、做测试，这才是它抽象隔离的核心价值。

内容的提问来源于stack exchange，提问作者John John