我正在查看处理MVC3 / .Net应用程序的数据库访问的类。
该类是静态的,为常见的数据库查询提供了很好的方便方法 - 各种各样的东西,如“GetColumnBValueForColumnA()”,以及更复杂的查询。对于给定的解决方案和域,它已被很好地考虑/优化。
虽然看到这个类是静态的,却引发了一些关于这可能是一个坏主意的遗忘的记忆(也许是在多线程的背景下?),我无法摆脱这种感觉。
将这种类保持为静态是一个好主意,还是应该为每次数据库调用实例化它?
答案 0 :(得分:5)
保持这种类是静态的,或者我应该是这样的,这是一个好主意 为每次数据库调用实例化它?
如果您关心应用程序各层之间的弱耦合,这些层的可重用性,单独的单元测试,则不应该执行上述任何操作。你应该使用抽象。
如果你不关心那些东西那么静态方法就好了。使用静态方法时唯一要小心的是设计它们以使它们为reentrant并且不依赖于任何共享状态以保证线程安全。在所有情况下,请确保通过将所有IDisposable资源(例如数据库连接和命令)包装在using语句中来正确处理它们。
答案 1 :(得分:2)
将这种类保持为静态是一个好主意,还是应该为每次数据库调用实例化它?
这些不是你唯一的两个选择。
该类应该不是静态的:通过使其成为面向对象编程的静态you relinquish a few important advantages,而实际上什么也没有。
相反,应该通过基于构造函数的依赖注入向控制器提供它的实例。然后,您的DI绑定代码确定是为每个请求重新实例化该类,还是最终使用单例。你可以随便改变它。
以下是一些优点:
我可以继续。静态类会扼杀你的灵活性,99%的时间都没有实际优势。