这里的哲学问题 说到OOP和数据库，特别是用数据库备份类的程序，最好的方法是什么？例如，团队类可能有一组玩家。该程序将在启动时从数据库加载所有团队数据，在内存中执行所有操作，然后在关闭时编写数据库。或者，当更改发生时，将每个数据操作写入数据库是否更好？如果这是更好的方法，为什么首先将数据加载到内存中？
另一个问题是，在我看来，数据库在一个重要方面打破了标准OOP。使用我的团队类和玩家集合，使用OOP，玩家类不需要拥有属性来保存团队名称。玩家将从其所属的团队类中获取团队名称。现在，为了将玩家保存在数据库中，每个玩家记录必须有一个列名称（或团队ID，但这是相同的事情）。
换句话说，如果你需要一个GetAllPlayers（）方法，你会让它成为团队类中的成员方法，从内存中返回集合中的所有玩家，或者在玩家类中创建一个静态方法从数据库中获取所有玩家？
任何人都有关于如何回答这些问题的任何提示？
自从我参加编程课以来已经有一段时间了。任何人都知道一本好的教科书，在这里了解最好的方法吗？
答案 0 :(得分：2)
数据库以更基本的方式打破面向对象。 （或者对象打破了关系模型。这取决于你是中层OO人还是DBA。）
关系数据库根据定义设置，本质上是声明性的。面向对象语言是基于对象实例的。由于“物体 - 关系阻抗不匹配”，使两者协同工作很困难。这就是为什么你会看到如此多的ORM解决方案（例如TopLink，Hibernate等）。所有这些解决方案都试图欺骗面向对象的程序员认为他们只需要处理对象而不用担心关系数据库。
但是你实现它，我认为持久性应该与模型对象分开。我通常将关系代码放在基于接口的数据访问层中。这样，模型对象不必知道它们是否持久化，并且我将CRUD操作隔离在一个包中。
至于推荐阅读，我会提供福勒的Patterns of Enterprise Application Architecture供你考虑。
答案 1 :(得分：0)
此方案的最佳解决方案实际上取决于大量变量。通常情况下，“分层”方法被认为是OO语言中最好的方法，但即使根据应用程序必须解决的每个问题的优先级，也会有无穷无尽的排列数。
您的代表对象（玩家，团队等）通常不应参与数据库操作，例如，该责任属于您的数据访问层。
学习面向对象思维方式的好方法是看一些设计模式。关于该主题的一本好的“易读”书我推荐的是“Head First Design Patterns”。它是Java语言，它涵盖了每个主题的各种角度。在我看来，它是“傻瓜”书籍水平与更抽象/理论书籍水平之间的良好桥梁。