在网站业务层中使用静态方法与实例化类然后在类上调用方法有什么缺点？无论哪种方式都有什么表现？
答案 0 :(得分：12)
性能差异可以忽略不计。
使用静态方法的缺点是它变得不太可测试。在静态方法调用中表示依赖关系时，不能用mocks / stubs替换这些依赖关系。如果所有依赖关系都表示为接口，其中实现被传递到组件中，那么您可以使用组件的模拟/存根版本进行单元测试，然后使用实际实现（可能与IoC容器连接）实现部署。
答案 1 :(得分：3)
Jon Skeet是对的 - 性能差异无关紧要......
话虽如此，如果您正在构建企业应用程序，我建议使用Microsoft和其他一些软件公司所支持的传统分层方法。让我简单解释一下：
我将使用ASP.NET因为我最熟悉它，但这应该很容易转换为您可能正在使用的任何其他技术。
应用程序的表示层将包含用于显示的ASP.NET aspx页面和用于“进程控制”的ASP.NET代码隐藏。这是一种讨论单击提交时会发生什么的奇特方式。我要去另一页吗？有验证吗？我是否需要将信息保存到数据库中？我去哪儿了？
流程控制是表示层和业务层之间的联络。这一层分为两部分（这是你的问题所在的地方）。构建此层的最灵活方式是拥有一组业务逻辑类（例如，PaymentProcessing，CustomerManagement等），这些类具有ProcessPayment，DeleteCustomer，CreateAccount等方法。这些将是静态方法。
当从流程控制层调用上述方法时，它们将处理业务对象的所有实例化（例如，客户，发票，付款等）并应用适当的业务规则。
您的业务对象可以处理与数据层的所有数据库交互。也就是说，他们知道如何保存他们包含的数据......这与MVC模式类似。
那么 - 这有什么好处？那么，你仍然可以在多个级别上获得可测试性。您可以测试UI，可以测试业务流程（通过使用适当的数据调用业务逻辑类），并且可以测试业务对象（通过手动实例化它们并测试它们的方法。您还知道，如果您的数据模型或者对象更改，您的UI不会受到影响，只有您的业务逻辑类必须更改。此外，如果业务逻辑发生更改，您可以更改这些类而不会影响对象。
希望这有点帮助。
答案 2 :(得分：3)
性能方面，使用静态方法可以避免对象创建/销毁的开销。这通常是不重要的。
只应在方法采取的操作与状态无关的情况下使用它们，例如，对于工厂方法。创建一个对象实例只是为了实例化另一个对象实例是没有意义的： - ）
String.Format（），TryParse（）和Parse（）方法都是静态方法有意义的好例子。它们总是执行相同的操作，不需要状态，并且相当常见，因此实例化不那么有意义。
另一方面，在没有意义的情况下使用它们（例如，必须将所有状态传递给方法，比如使用10个参数），会使一切变得更复杂，可维护性更低，可读性更低且可测试性更低正如乔恩所说。我认为，如果这是关于业务层或代码中的任何其他地方，只是谨慎地使用它们并且在情况合理时使用它们是不相关的。
答案 3 :(得分：0)
如果该方法使用静态数据，则实际上将在您的Web应用程序的所有用户之间共享。
仅限代码，除了所有系统中静态方法的常见问题外，没有任何实际问题。
答案 4 :(得分：0)