通过一个Database类访问数据库，紧耦合？打破SRP？

Question

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

我想知道我的论点是否有效，然后才告诉他们，所以这里是：

• 这样做会破坏SOLID单一责任原则（SRP）
• 它引入了我们所有需要Database类
的类之间的紧密耦合
• 隐藏我们的对象依赖
• 使单元测试更加困难
• 介绍不必要的全球状态

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

感谢。

Answer 1

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

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