对于IoC容器，构造函数是否仍应检查参数是否为null

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

不管怎样，安全总比抱歉好。在这种情况下，最好花几秒钟的时间保护代码，然后在有人决定将其作为意外使用时花几个小时。

我不会检查。我认为这会不必要地扰乱你的构造函数。

如果您的DI容器没有所需的依赖性，那么您的手动或自动测试应该会很快发现这一点。

通过将某个东西作为构造函数的参数，你就意味着它是必需的。

此外，如果您以某种方式获得了一个null参数，该怎么办？

构造函数是否尝试构造一个null类型的new？可能不是因为这个构造函数应该不知道传入类型需要实例化什么。

在这一点上，您应该只捕获异常并优雅地退出或继续；但无论如何，您都应该有针对这种情况的代码。

是。类设计必须不知道如何注入其依赖项，并且必须始终保护其不变量。

最新版本的Ninject和Structure映射在进入构造函数之前都会抛出绑定异常。因此，在构造函数中检查参数null异常无论如何都没有帮助。

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

我并不是说防御代码没有位置，但如果你使用的是现代IoC，构造函数检查就不存在了。

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

对我来说，有人进来需要阅读你的代码的可能性要高得多。更容易阅读的代码通常不太可能出现错误，而且维护起来也更快。