使用IoC容器，构造函数是否仍应检查参数是否为null？

Question

我正在查看Orchard CMS Project源代码，我注意到他们的一些构造函数从未验证所需参数不为null。起初，我觉得这很奇怪。我问自己，“考虑到你说这种依赖是必需的，你不想检查你确实有一个吗？”意识到该项目使用Castle Windsor作为IoC容器，后来我想，“好吧，当它试图找到具有该要求的对象的依赖时，容器会抛出异常。”所以我的问题是，如果我知道IoC容器会检查我，我还应该检查吗？

或者是双重检查是好的，因为从某种意义上说，我坚持反向封装原则，说：“我不知道我是如何得到这种依赖，但我真的需要一个！”

Answer 1

我被引导遵循检查NULL的每个可见参数的做法，无论它是如何被设计为实例化的。总是有人会选择一个不同的IoC容器来强制执行更宽松的类型委派策略，或者一些初级开发人员找到你的代码并希望它能以他们想要的方式工作。

无论哪种方式，比抱歉更安全。在这种情况下，当有人决定将其用作无意识时，最好花几秒钟保护代码。

Answer 2

我不会检查。我认为它会不必要地使你的构造者混乱。

如果您的DI容器没有所需的依赖关系，那么您的测试，手动或自动应该很快就能解决这个问题。

通过将某些内容作为构造函数的参数，您说它是 required 。

另外，如果你以某种方式得到一个空参数，你会怎么做？

构造函数是否尝试构造一个新的null类型？可能不是因为这个构造函数不知道传入的类型需要实例化它自己。

此时你应该抓住异常并优雅地退出或继续前进;但无论如何你应该有这种情况的代码。

Answer 3

是。类设计必须与其依赖关系的注入方式无关，并且必须始终保护其不变量。

Answer 4

最新版本的Ninject和Structure映射都会在您输入构造函数之前抛出绑定异常。 因此，在构造函数中检查参数null异常无论如何都无济于事。

所以我投票保持你的代码干净。

我并不是说防御性代码没有位置，但如果您使用的是现代IoC，则构造函数检查不是一个。

虽然将来有人可能会选择不执行严格类型委派政策的不同IoC容器。我觉得这是一个“假设”的论点，改变IoC是一个相当大的架构决策，个人自动生成空检查的成本可能不会对它产生太大影响。

对我而言，有人进入并需要阅读您的代码的可能性更高。更容易阅读代码通常不太可能出错，并且维护起来也更快。