为什么我会使用静态方法进行数据库访问

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

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

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操作，也不适用于与数据库相关的更具体任务。

这是与访问数据库的特定方式有关的东西，是一些可以提供（甚至是非常小的）性能提升的实践，或者它只是开发人员的方法，我不应该在和何时不在我的数据库中使用静态方法相关的方法？

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

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

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

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

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

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

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

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

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

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

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

来源 – MSDN