使用静态方法与数据库连接 - 任何潜在的问题?

时间:2012-01-23 21:20:56

标签: .net asp.net-mvc-3 database-abstraction static-class

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

该类是静态的,为常见的数据库查询提供了很好的方便方法 - 各种各样的东西,如“GetColumnBValueForColumnA()”,以及更复杂的查询。对于给定的解决方案和域,它已被很好地考虑/优化。

虽然看到这个类是静态的,却引发了一些关于这可能是一个坏主意的遗忘的记忆(也许是在多线程的背景下?),我无法摆脱这种感觉。

将这种类保持为静态是一个好主意,还是应该为每次数据库调用实例化它?

2 个答案:

答案 0 :(得分:5)

  

保持这种类是静态的,或者我应该是这样的,这是一个好主意   为每次数据库调用实例化它?

如果您关心应用程序各层之间的弱耦合,这些层的可重用性,单独的单元测试,则不应该执行上述任何操作。你应该使用抽象。

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

答案 1 :(得分:2)

  

将这种类保持为静态是一个好主意,还是应该为每次数据库调用实例化它?

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

该类应该是静态的:通过使其成为面向对象编程的静态you relinquish a few important advantages,而实际上什么也没有。

相反,应该通过基于构造函数的依赖注入向控制器提供它的实例。然后,您的DI绑定代码确定是为每个请求重新实例化该类,还是最终使用单例。你可以随便改变它。

以下是一些优点:

  1. 假设您要对依赖此数据访问类的方法进行单元测试。如果您使用注入的服务接口而不是直接调用静态方法,您可以创建一个Mock对象,告诉它如何表现,并允许您进行单元测试的方法认为它变得真实数据实际上你只是在为它提供你要测试的数据。
  2. 假设您最终想要缓存数据访问调用的结果。您可以注入一个包装实际类的缓存类,尽可能返回缓存结果,并在缓存值不存在时调用实际数据访问方法。这些都不需要对您的数据访问类进行任何更改。
  3. 我可以继续。静态类会扼杀你的灵活性,99%的时间都没有实际优势。