Database 使用类和数据库编程

这里的哲学问题 对于OOP和数据库，特别是使用数据库备份类的程序，最好的方法是什么？例如，一个团队类可能有一组玩家。程序将在启动时从数据库加载所有团队数据，在内存中执行所有操作，然后在关闭时写入数据库。还是在发生更改时将每个数据操作写入数据库更好？如果这是更好的方法，为什么首先要将数据加载到内存中

另一个问题是，在我看来，数据库在一个重要方面打破了标准OOP。使用带有玩家集合的my team类，使用OOP，玩家类不需要有一个属性来保存团队名称。玩家将从其所属的团队类中获取团队名称。现在，为了在数据库中保存球员，每个球员记录都必须有一列球队名称（或球队id，但这是一样的）

换句话说，如果您需要一个getAllPlayer（）方法，您会将其设置为team类中的成员方法，以从内存中返回集合中的所有玩家，还是在player类中设置一个静态方法以从数据库中获取所有玩家

有人知道如何回答这些问题吗

---

我已经有一段时间没有上编程课了。有谁知道一本好的教科书可以用来理解这里的最佳方法吗？

数据库以一种更基本的方式打破了面向对象。（或者对象破坏了关系模型。这取决于您是中间层OO人员还是DBA。）

关系数据库是根据定义设置的，本质上是声明性的。面向对象语言是基于对象实例的。由于“对象关系阻抗失配”，使两者一起工作很困难。这就是为什么你会看到如此多的ORM解决方案（例如TopLink、Hibernate等），它们都试图愚弄面向对象的程序员，使他们认为他们只需要处理对象，而不用担心关系数据库

无论您如何实现它，我认为持久性应该与模型对象分开。我通常将关系代码放在基于接口的数据访问层中。这样模型对象就不必知道它们是否被持久化，我将CRUD操作隔离在一个包中

---

至于推荐阅读，我将提供Fowler's供您考虑。

此场景的最佳解决方案实际上取决于大量变量。通常，在OO语言中，“分层”方法被认为是最划算的方法，但即使这样，基于应用程序必须解决的每个问题的优先级，也有几乎无限多的排列

您的代表性对象（玩家、团队等）通常不应参与数据库操作，因为该职责将属于您的数据访问层

---

学习面向对象思维的一个好方法是看一些设计模式。关于这个主题，我推荐一本很好的“易读”的书是“Head-First Design Patterns”，它是用Java编写的，并且在它所涵盖的每个主题上提供了各种角度。在我看来，它在“傻瓜”书籍和更抽象/理论书籍之间起到了很好的桥梁作用。

我没有听说过“对象关系阻抗不匹配”这个术语。我确实在网上看到了一些关于它的好消息，这将有所帮助。我真的很喜欢你的想法，把所有坚持的东西都拿出来。我一直讨厌在我的课堂上使用这种代码+1，但我会暂时不回答，看看还有什么其他评论。没关系。祝你狩猎好运。当然不是不可能。没人说是。有很多成功的系统使用关系数据库，对象位于中间层。谁说不可能？请指出。看看Hibernate/NHibernate。他们正试图解决这类问题。它不是完美的，它不是简单的事情。在这里，您可以看到基于关系数据库编写OO代码是多么复杂。