我可以在业务逻辑中使用静态类吗？ [关闭]答案

【问题标题】：Can I use static class in business logic? [closed]我可以在业务逻辑中使用静态类吗？ [关闭]
【发布时间】：2017-02-16 12:30:45
【问题描述】：

这可能是一个重复的问题，但让我们谈谈无状态应用程序，如 WEB API、ASP.NET、WCF。所有这些都是无状态的应用程序。那么，我可以在业务逻辑中使用静态类吗？因为静态应用会工作得更快。

在我们的 ASP.NET MVC 应用程序中，我们有单独的项目（库）用于业务逻辑。我们正在使用静态类。这是使用静态的好方法吗

【问题讨论】：

“因为静态应用会工作得更快”是谁告诉你的？
代码并不胖，因为它是静态的。事实上，它可能会更快，因为它被初始化一次，而不是缓存，但这也适用于非静态类。
不是静态类更快，而是静态方法比实例方法更快......但是差异是如此之小以至于可以忽略不计。（静态方法更快，因为它们没有包含this 引用的“隐藏”参数...少一个参数->调用速度更快）。静态类纯粹是 C# 的语法糖（它们不存在于 IL 中间语言中）
@xanatos 这就是为什么我什至不会提及这一点，以避免在此重构没有带来可衡量的改进时为了速度而进行重构。
感谢您所有明确的解释。但你对此有何看法。按需创建的对象（堆内存）意味着运行时间。因此，通过 Web 应用程序设计，静态行为更快。在第一次应用程序加载时加载的所有类和创建的内存，只要应用程序运行，这将被重用

【解决方案1】：

使用静态类有一个很大的缺点：它们非常难以模拟以进行单元测试（甚至单元测试也更加困难，具体取决于所使用的框架）。即使是静态方法也很难模拟。静态类并没有真正的优势，所以答案是：不要将静态类用于业务逻辑。不要将静态方法用于业务方法。

【讨论】：

【解决方案2】：

否，因为当您使用静态类时，这意味着您不想创建该类的实例，这是业务逻辑的一个非常落后的案例。

【讨论】：

【解决方案3】：

它不好有几个原因：

简而言之，尽量避免使用静态代码，除非它像扩展方法之类的那样大喊“静态”。干净的代码和可靠的原则可以让你更深入地理解为什么你应该避免它。

【讨论】：