我应该在不能使用类的控制器中使用 Lazy<T> 吗？答案

【问题标题】：Should I use Lazy<T> in a controller where a class may not be used?我应该在不能使用类的控制器中使用 Lazy<T> 吗？
【发布时间】：2015-03-18 05:25:08
【问题描述】：

我正在编写一个 MVC 5 互联网应用程序，并且有一个关于使用惰性和惰性初始化的问题。

Lazy Class 文档说：

使用延迟初始化来推迟创建大型或资源密集型对象，或资源密集型的执行任务，特别是当此类创建或执行可能不会发生时在程序的生命周期内。

这是我的情况：

我有一个具有验证服务类的控制器。此服务类仅在控制器创建或编辑函数中创建或编辑模型对象时使用。

我应该在这个验证类中使用 Lazy 吗？我在想也许，因为用户可以浏览到索引、详细信息和删除功能，并且永远不会使用验证服务类。验证类有超过 900 行代码。

另外，我有一个异常服务类，用于在发生错误时显示自定义错误页面。该异常类有 100 行代码，仅在发生异常时使用。如果没有发生异常，则不会使用此类。我应该为这个异常类使用 Lazy 吗？

由于我之前没有使用过Lazy，所以请教一下，我不确定是否应该在上述两种情况下使用Lazy。

提前致谢。

编辑

有人可以解释一下在上述情况下是否有任何理由不使用 Lazy 吗？异常缓存是我需要担心的吗？

验证服务类有一个接受IGenericMultipleRepository 对象的构造函数。该对象是用于访问存储库的接口，我在单元测试时使用它。 Exception 服务类有一个默认构造函数。

【问题讨论】：

【解决方案1】：

我肯定会为验证服务使用延迟初始化。对于异常处理程序，您可以采用任何一种方式 - 预期会出现异常。延迟初始化的好处是您的代码响应速度更快并且使用的资源更少。缺点是要学一门新课。一旦你学会了它，你可以在很多地方使用它。

【讨论】：

【解决方案2】：

代码行与实例化类的运行时成本几乎没有关系。如果没有静态变量并且您有一个空的构造函数，那么实例化您的验证或异常类将会很便宜。

一个更重要的问题是，通过使用 Lazy 或直接实例化它们，您会将控制器类与这些服务类紧密耦合，这使得单独测试它们变得更加困难。

没有看到代码很难准确地说出来，但我怀疑你最好使用依赖注入将每个类注入控制器（并为每个类提供一个接口）。

通过这种方法，您可以独立测试每个类，您可以用一个 mock 代替验证类和异常类，并且您可以在下次拥有一个不需要的控制器时重用这些类。

如果一个类的实例化成本很高，您仍然可以使用依赖注入容器，但您可以使用Func<T> 依赖。参见例如Autofac。

我还应该补充一点，实例化成本高昂的类本身通常是个坏主意：构造函数不应该做大量工作。

【讨论】：