java - 设计保存在数据库中的对象是否有普遍接受的做法？

Question

在设计经常从数据库加载和保存的 Java 对象时，是否有普遍接受的做法？

我现在使用的方法是有一个主要的数据库对象，它打开一个到数据库的连接。在我的应用程序中任何需要加载或保存对象的地方，我都会创建一个用于加载和保存的源接口(interface)。例如，我可能会这样做:

public interface CalendarSource {
  public Appointment[] getAppointmentsForMonth(int year, int month);
  public void saveAppointment(Appointment appointment);
}

然后我将在主数据库对象上实现该接口(interface)。任何子数据也同时加载到主对象内部的成员对象中。就像每次约会都有一份客人名单一样。这很有效，因为我使用的所有数据都来自两个数据库之一，所以我保持两个数据库连接，每个源都由其中一个实现。

问题是这有时看起来很笨拙。如何处理 ID 值令人困惑，因为我真的不想将它们添加到我的对象中。它还需要一个数据库连接来实现多个不同的接口(interface)。实际上，我的数据库包必须依赖项目中的几乎每个包，因为它实现了所有接口(interface)。这在一定程度上确实有意义，但我想知道是否有更好的方法。

我选择这个架构的主要原因有两个:

• 我希望我使用的对象不知道它们是从数据库中加载还是保存的。为了便于移植，我将来可能想用平面文件替换此数据库源。
• 我想要一个良好的包依赖层次结构。应隔离数据库代码，以便可以轻松地将对数据库架构的更改更新到代码中。

我遇到的一个问题是如何处理 ID 值。由于对象不应该知道它们是数据库对象，因此它们中不应该有 ID 字段。但是，如果我尝试将一个对象写入数据库，但我没有 ID 值，我该如何知道我应该执行插入还是更新？

我还担心让数据库包扩展整个项目的所有内容。我不断地传递这些源接口(interface)。我想这也是有道理的。

也许我只是在寻找一些证明我做对了的验证，这里没有我没有看到的明显简单的解决方案。不要误会我的意思 - 一切正常。

有什么想法吗？

Answer 1

我认为最通用的模式是 DAO 模式。即数据访问对象。基本上，您定义一个指定行为的接口(interface)(如基本的 crud 操作和您的域的专门行为)，然后您提供实现。对于额外的点，您可以使用泛型是 java 5 和更高版本来编写更少的代码。

http://www.ibm.com/developerworks/java/library/j-genericdao.html

将所有持久性代码保留在应用程序的一层中是一个重要的设计选择。它有助于保持代码简单和干净。

从你的帖子来看，你不想做你正在做的事情。使用 Spring 或等效工具，因为它会为您处理大量代码。它管理连接、事务等。

另外，不用担心类中有 ID 字段。虽然您可能认为它并不完美，但它让生活更轻松。选择参加更大的设计斗争，例如进行 TDD 和保持设计整洁。