DAO 是否应该扩展数据对象？

Question

我有一个名为Measurement 的类，它基本上只是一个带有一些成员的普通旧Java 对象，它实现了Parcelable 接口以便于序列化。

我想将来自 Measurement 对象的数据存储在 SQLite 数据库中。我需要一种简单的方法来传递带有附加数据库 ID 的数据。我的第一个解决方案是简单地将public long id 成员添加到Measurement 类。这当然行得通，但感觉就像它与数据库耦合，这实际上没有意义 - Measurement 可以在没有数据库的情况下存在，并且用于根本没有数据库概念的各种地方.

所以，我的下一个想法是创建某种MeasurementDbEntry，它将扩展Measurement 并添加public long id。然后，这将在与包含数据库 ID 相关的地方使用。这是一个好的设计，还是如果MeasurementDbEntry 没有扩展Measurement 而是有一个Measurement 成员和一个id 成员会更好？

另外，在问题标题中我提到了Data Access Object (DAO)，但我不确定我在这里谈论的是否真的是一个 DAO，因为它并没有真正访问数据库本身（我是使用SQLiteOpenHelper 的子类来做到这一点）？它只是Measurement 的更特定于数据库的表示。它会被视为 DAO（我应该将我的班级命名为 MeasurementDAO）吗？

Answer 1

我的个人观点 - 维护一个单独的类（无论它是否使用继承或组合）的额外努力是否值得？ ID 属性只是一个属性 - 我没有明确地将其视为与数据库的耦合（这不像您将与 DB 相关的依赖项拉入您的 Measurement 类）。

如果是我，我会更新 Measurement 类 - 此外，如果您要在其他任何地方读/写它，您可能仍然需要 ID，这意味着您仍将传递它到处都是，无论如何都不会直接使用底层的Measurement类。

是的，我同意 - 你所说的类听起来不像 DAO - 更像是 DTO。

Answer 2

您完全正确，将DBEntry DAO 保持为单独的实体总是更好。

让我们考虑memory， 假设您的类Measurement 需要保存在Database 中，这需要10 更多的附加属性，但是在实时你不会在整个应用程序中使用它们，那么如果你对两者都使用相同的模型它会在您访问时消耗一些未使用的内存，显然在这种情况下创建单独的实体是显而易见且非常受欢迎的解决方案。

始终为可扩展性设计应用程序，今天id 是唯一的属性，明天您可能必须添加一些其他附加属性，仅用于保存在Database 中。这种设计将来可以为您提供方便。