c# - 为什么我要使用静态方法进行数据库访问

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

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

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

没有替代实现，没有测试 stub ，根本没有依赖倒置。业务逻辑有一个依赖箭头指向基础设施问题(数据访问层)，而这应该是相反的方式。

---

此外，这似乎至少带来了更大的风险，即在资源处置方面出现问题。这里可能不是这种情况，但它很容易成为这种情况。如果某个地方的开发人员有一个绝妙的主意，可以将通用代码行提取到类级静态方法和属性中怎么办？像 Connection 或 DBContext 对象？这会产生一些非常有趣且非常难以调试的运行时错误。

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

---

继续(我想我对设计的反对意见比我想象的要多)，从面向对象的角度来看，这感觉对我来说非常违反直觉。也许这只是个人喜好，但这正在将原本是“存储库对象”的东西变成“数据库辅助方法的垃圾场”。

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