我正在寻找一个处理 MVC3/.Net 应用程序的数据库访问的类。
该类是静态的，并为常见的 DB 查询提供了很好的便利方法 - 诸如“GetColumnBValueForColumnA()”之类的各种有趣的东西，以及更复杂的查询。它针对给定的解决方案和域很好地考虑/优化。
但是，将类视为静态的，引发了一些关于这可能是一个坏主意的半遗忘记忆（也许在多线程的上下文中？），我无法摆脱这种感觉。
保持这种类静态是个好主意，还是应该为每个数据库调用实例化它？
问问题
1766 次
2 回答
5
保持这种类静态是个好主意，还是应该为每个数据库调用实例化它？
如果您关心应用程序各层之间的弱耦合、这些层的可重用性、孤立的单元测试之类的事情，那么您不应该做上述任何事情。您应该使用抽象。
如果您不关心这些事情，那么静态方法就可以了。使用静态方法时唯一需要注意的是将它们设计为可重入且不依赖于任何共享状态以实现线程安全。在所有情况下，请确保通过将所有 IDisposable 资源包装在 using 语句中来正确处置所有 IDisposable 资源，例如数据库连接和命令。
于 2012-01-23T21:22:32.750 回答
2
保持这种类静态是个好主意，还是应该为每个数据库调用实例化它？
这些不是您唯一的两个选择。
类不应该是静态的：通过将其设为静态，您放弃了面向对象编程的一些重要优势，而实际上一无所获。
相反，它的一个实例应该通过基于构造函数的依赖注入提供给你的控制器。是否为每个请求重新实例化该类，或者您最终是否使用单例，然后由您的 DI 绑定代码确定。您可以随时更改它。
这里有几个优点：
- 假设您要对依赖此数据访问类的方法进行单元测试。如果您使用注入的服务接口而不是直接调用静态方法，则可以创建一个 Mock 对象，告诉它如何表现，并允许您正在单元测试的方法认为它正在获取真实数据，而实际上您正在只是给它你想要测试的数据。
- 假设您最终想要缓存数据访问调用的结果。您可以注入一个封装实际类的缓存类，在可能的情况下返回缓存结果，并在缓存值不存在时调用真正的数据访问方法。这些都不需要对您的数据访问类进行任何更改。
我可以继续。静态类会扼杀你的灵活性，并且在 99% 的情况下都没有实际优势。
于 2012-01-23T21:25:32.427 回答