C# 为什么我要使用静态方法访问数据库

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

现在我正在从事一个项目，其中所有内容都是通过存储过程完成的，例如，我有一些常规方法，如：

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

或

但我也有：

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

或

由于我在

.NET

工作了大约9个月，并且只使用了

实体框架

和

存储库模式

，所以我想不起使用静态方法的任何地方或任何代码。不适用于标准

CRUD

操作，也不适用于与数据库相关的更具体的任务

---

那么，这是否与数据库访问的特定方式有关，是否有一些实践可以（即使是非常小的）提高性能，或者这只是开发人员的方法，我不应该过多考虑什么时候以及什么时候不在我的数据库相关方法中使用静态方法？

我认为你的最后一句话是正确的；这只是以前的开发人员方法

---

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

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

我们公司很少使用静态方法，尽管它们可以在实用类或类似于调用函数的东西中发挥作用。根据您对一个非静态类的期望实例数，它们也会影响性能，但这需要一个显著的实例差异

---

source-

在数据访问层的特殊情况下，我会避免使用静态方法，原因很简单。。。耦合

静态方法不能实现接口，实例方法可以。通过使用静态方法，人们本质上反对将代码编码到接口，而不是编码到实现。因此，使用此数据访问层的所有内容都需要始终访问此特定数据访问层

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

---

此外，这似乎至少会带来更大的资源处置问题风险。这里可能不是这样，但它很容易变成这样。如果某个开发人员有一个聪明的想法，将公共代码行提取到类级静态方法和属性中，该怎么办？类似于

连接

或

DBContext

对象？这将产生一些非常有趣且非常难以调试的运行时错误

另一方面，如果存储库是实例，那么它们可以简单地实现

IDisposable

，并确保正确地处理任何类级对象

---

继续（我想我对这个设计的反对比我想象的要多），从面向对象的角度来看，这让我感觉非常不直观。也许这只是个人喜好，但这将把原本是“存储库对象”的东西变成“DB助手方法的转储场”

---

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

@Anon是的，这是ASP.NET Web Forms applicationMore reading：我们无法从发布的示例中确定，但是如果这些方法只是调用存储过程，那么这里可能没有什么可测试的，也没有什么可模仿的。当然，这些方法是静态的没有问题，但是我想知道还有什么比使其成为静态的能力更重要的原因吗。它工作得很好，但从我所看到的来看，这是我第一次看到有人把这种方法变成静态的，从我的经验来看，这不是常见的做法。当然，我也可能错了，所以我要求..+1提及调用存储过程可能导致唯一的共享数据是连接字符串。我们在软件中使用它来维护数据的一致性和安全性。我印象深刻的是，一件事是多么容易，甚至是不可察觉的，它会导致另一件事，并最终导致

“臃肿且难以遵循的代码库”

。我会把你的答案读好几遍，真的很好。谢谢。这个回答太棒了，非常完美地描述了我在尝试将单元测试添加到我接手的现有web应用程序项目中时所经历的痛苦。我一定会利用这个答案继续前进！

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

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