生产代码中的简单注射器Verify（）

Question

在生产代码中调用container.Verify()是否是最佳实践？我想移动到的：

#IF Debug 
    container.Verify(); 
#ENDIF 

我没有任何真正的理由做出改变，只是好奇，普遍的共识/最好的做法是什么。

Answer 1

致电Verify是否有用可供讨论。早在2011年，Mark Seemann确实认为such a method is close to worthless。我的意见是，在调用Verify时有实际价值，但我理解Mark的情绪并同意自己调用Verify通常是不够的。这就是为什么Simple Injector wiki上的Verifying the container’s configuration有关于保持您的DI配置可验证的明确指南。

但是，使用简单的喷油器，Verify不仅仅是测试它是否可以创建对象图。拨打Verify的电话将启动Simple Injector的Diagnostic Services，该搜索非常常见，但有时很难找到配置错误（Mark在写这篇文章时没有提供的功能）。

一般来说，我的建议是在生产代码中尽可能长时间地致电container.Verify。无论是在调试版本还是发布版本，在分段环境和生产环境中，始终都要称它为启动。

随着应用程序变得越来越大，在启动过程中致电container.Verify会变得更加耗时。某些类型的应用程序比其他应用程序更敏感。对于服务器应用程序，启动时间较长通常是可以的，而桌面和移动电话应用程序必须更快启动。

当您进入电话号码Verify需要的时间过长时（但只有这样），您应该将电话号码除去Verify，但至少仍然有一个称为container.Verify的单元/集成测试。我发现在编译器指令中包装Verify没问题（就像你在你的问题中做的那样），但是再次注意IMO应尽可能延迟在启动路径中去除对Verify的调用。