通过一个数据库类访问数据库，紧耦合？破坏 SRP？答案

【问题标题】：Accessing the database through one Database class, tight coupling? Breaks SRP?通过一个数据库类访问数据库，紧耦合？破坏 SRP？
【发布时间】：2013-03-16 10:59:48
【问题描述】：

我正在和几个人一起开发一些软件，从完成的类图中有一个Database 类，例如Order 类有两个构造函数，一个没有参数，一个除了id .它还有一个save() 方法，因此我假设如果您在构造函数中提供id，该类将使用Database 类并填充对象属性，并且没有地方注入它Database 类在构造函数或 setter 方法中，所以我认为他们想使用 Singleton。

在对他们说之前我想知道我的论点是否有效，所以他们在这里：

这样做违反了 SOLID 单一职责原则 (SRP)
它在我们所有需要 Database 类的类之间引入了紧密耦合
它隐藏了我们的对象依赖关系
它使单元测试更加困难
引入不必要的全局状态

它们会是有效的论据吗？这样做还有什么缺陷吗？如果我的观点是有效的，是否值得对他们说？

谢谢。

【问题讨论】：

基本方法听起来不错，但实现听起来很糟糕。你是对的，实现细节应该被隐藏/解耦。更好的实现可能是使用工厂。不确定第一点，第二点我认为有效，因为很容易证明更改数据库很容易破坏实现。不确定其他两个。我认为你有一些正当的理由担心，但你需要平衡需求与未来的期望
感谢您的回复。证明更改数据库很容易破坏实现的最佳方式是什么？
考虑到 JDBC 驱动程序之类的好东西，这并不总是听起来那么容易。一个问题是，如果他的数据库改为 Web 服务
好的，谢谢，我会继续研究。

标签： java php c++ oop

【解决方案1】：

这是一个众所周知的模式，称为active record。它通常用于几个大型框架，例如 Ruby on Rails。它确实有你提到的缺点，我认为你应该强调潜在的问题，但并非没有任何替代方案可供讨论。

一个常见的替代方法是使用服务外观来保存对象 - 一组 DAO。使用这种模式，您可以更明确地访问数据库并且不太方便，但 IMO 会减少主应用程序中的数据库耦合。正如您所提到的，从 SRP 的角度来看，这更好，这使得测试变得更加容易。

【讨论】：

感谢您的回复。是的，我正在考虑提到 DAO 或 DataMappers 以将数据库逻辑排除在业务对象之外，并且通过这样做，我们将遵守 SRP，删除单例，删除隐藏的依赖项和全局状态以及紧密耦合，并使单元测试更容易。这一简单的改变具有巨大的优势，所以希望他们会听我的。
如果他们将任何东西建模为 Singleton，您必须告诉他们停止！我错过了你帖子的那部分。