IoC 带来的麻烦值得吗

标签：stack   缺点   成员变量   ons   com   全局   带来   优缺点   理解   

https://stackoverflow.com/questions/39626194/should-i-avoid-using-dependency-injection-and-ioc

使用 ioc 时貌似需要写不少的 boilerplate 代码，有时候会困惑是否值得。这篇帖子探讨了其优缺点。

题主有个说法是使用 ioc 的样板代码可能会不利于 creative people 写代码。然而反面的意见是，"writing code is not an art, it‘s a craft". 所以，到底是要取悦所谓 creative people，还是要创建长期可维护可理解的代码，需要自己衡量。

另外，关于 ioc 需要在构造器中注入依赖的类实例，然后又要写样板代码复制到成员变量的情况，C# 高版本后可能会通过语法糖进行改进。同时需要注意的是，一般构造器注入的是必须的依赖。而通过属性直接注入的，是可选依赖。如果通过属性注入的依赖过多，本身已经是一种坏味道，违反 SRP (单一职责原则)。

关于难以跳转到定义的问题，VS 高版本可以按 Ctrl + F12 解决。

ioc 最大的好处是通过类的依赖关系定义，避免了手工创建实例，避免全局状态（类似静态变量）的使用，代码可预测性比较好，也方便 mock 和测试。

另外在这个帖子里 https://softwareengineering.stackexchange.com/questions/159554/dependency-injection-good-practices-to-reduce-boilerplate-code, 有讨论到在用了 DI 的情况下如何减少样板代码。具体来说，就是如果有个类全局到处都要用到，那可能不应该对他使用 DI. DI 主要是用于那些必须解耦的类身上的。

IoC 带来的麻烦值得吗

标签：stack   缺点   成员变量   ons   com   全局   带来   优缺点   理解   

原文地址：https://www.cnblogs.com/new-start/p/13200849.html