关于.net：使用静态方法与数据库连接 – 任何潜在的问题？


Using static methods to interface with a database - any potential problems?

我正在查看一个处理MVC3/.NET应用程序数据库访问的类。

这个类是静态的，为常见的DB查询提供了很好的方便方法——各种各样的琐碎的东西，比如"getColumnBValueforColumna()"，以及更复杂的查询。对于给定的解决方案和领域，它被很好地分解/优化。

不过，将类视为静态类会引发一些被遗忘了一半的内存，说明这可能是一个坏主意(可能在多线程环境中？)我无法动摇这种感觉。

保持此类静态是个好主意，还是应该为每次数据库调用实例化它？

相关讨论

Is it a good idea to keep this kind of class static, or should I be
instantiating it for each database call?

如果您关心诸如应用程序层之间的弱耦合、这些层的可重用性、隔离的单元测试之类的事情，那么您不应该这样做。你应该使用抽象。

如果你不关心这些事情，那么静态方法就可以了。在使用静态方法时要小心的唯一一件事是设计静态方法，使它们是可重入的，并且不依赖于任何共享状态，以保证线程安全。在所有情况下，请确保通过将所有IDisposable资源(如数据库连接和命令)包装在using语句中来正确地处置它们。

相关讨论

Is it a good idea to keep this kind of class static, or should I be instantiating it for each database call?

这不是你唯一的两个选择。

这个类不应该是静态的：通过使它成为静态的，您放弃了面向对象编程的一些重要优势，而实际上什么也得不到。

相反，它的一个实例应该通过基于构造函数的依赖注入提供给控制器。然后，由DI绑定代码决定类是为每个请求重新实例化，还是最终使用单例。你一戴帽子就可以换。

以下是几个优点：

  • 假设您想对依赖于这个数据访问类的方法进行单元测试。如果您使用的是注入的服务接口而不是直接调用静态方法，那么您可以创建一个模拟对象，告诉它如何工作，并允许单元测试中的方法认为它正在获取真实数据，而实际上您只是向它提供您想要测试的数据。
  • 假设您最终想要缓存数据访问调用的结果。可以插入一个包装实际类的缓存类，在可能的情况下返回缓存结果，并在缓存值不存在时调用实际数据访问方法。所有这些都不需要对数据访问类进行任何更改。

    • 我可以继续下去。静态类会破坏您的灵活性，99%的时间内没有实际的优势。