Question

所以我今天遇到了这个问题，我找不到一些有意义的解释是否有一些非主观的理由在数据库交互时使用静态方法。

现在我正在开发一个项目，通过存储过程完成所有事情，例如我有一些常规方法，如：

public void Delete(int clientID)
    {
      //calling store procedure
    }

或

public void Save(int clientID)
    {
      //calling store procedure
    }

但我也有：

public static Client GetByID(int id)
    {
        //calling stored procedure
    }

或

public static int AddNew(string firstName, string lastName...)
    {
      //calling store procedure
    }

因为我在.NET工作了大约9个月而且我一直只使用Entity Framework和Repository Pattern我无法回想起静态方法所在的任何地方或代码用过的。不适用于标准CRUD操作，也不适用于与数据库相关的更具体任务。

这是与数据库访问的特定方式有关的事情，是否可以提供（甚至是非常小的）性能提升，或者只是开发人员方法，我不应该给它太多在我的数据库相关方法中何时何地不使用静态方法？

Answer 1

在数据访问层的特定情况下，我会出于一个简单的原因避免使用静态方法......耦合。

静态方法无法实现接口，实例方法可以。通过使用静态方法，基本上坚持不对编码到接口而是编码到实现。因此，使用此数据访问层的所有内容始终 此特定数据访问层。

没有替代实现，没有测试存根，根本没有依赖性反转。业务逻辑具有指向基础架构关注点（数据访问层）的依赖关系箭头，而这应该是另一种方式。

此外，这似乎至少会带来更大的风险处理资源的问题。这可能不是这种情况，但它很容易成为案例。如果开发人员有一个明智的想法将常见的代码行提取到类级静态方法和属性中会怎样？像Connection或DBContext对象之类的东西？这将创建一些非常有趣且非常难以调试的运行时错误。

另一方面，如果存储库是实例，那么他们可以简单地实现IDisposable并确保正确处理任何类级对象。

继续（我想我对设计的反对意见比我想象的要多），这种感觉从面向对象的意义上来说非常违反直觉。也许这只是个人偏好，但这会将原本可能成为“存储库对象”转变为“数据库助手方法的倾销”。

在这样的系统中，随着开发人员在不考虑整体架构的情况下快速制定满足要求的解决方案，我预计随机一次性方法的数量会随着时间的推移而显着增长。而不是一致且管理良好的一系列对象，你很可能最终会遇到一个臃肿且难以理解的代码库。

Answer 2

当没有状态或共享状态时，使用静态方法。如果您的代码只是调用存储过程，那么它可能没有共享数据库连接字符串以外的状态。这将是静态方法的有效使用。

Answer 3

我认为你的最后陈述是正确的;它只是以前的开发人员方法。

但是，我会说，让这些方法保持静态会让你的生活成为制造可测试产品的噩梦;如果您有能力将它们更改为基于实例并创建一组单元测试，可以通过模拟测试应用程序而无需数据库，那么从长远来看，它将使您的生活更轻松。

Answer 4

我们很少在公司中使用它们，尽管它们可以用于实用程序类或简单调用函数的类型。根据您对非静态类的预期实例数量，它们也会影响性能。但这需要是一个值得注意的实例差异。

来源 - MSDN