我有一个名为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，因为它本身并不真正访问数据库（I我正在使用SQLiteOpenHelper的子类来做到这一点？它只是Measurement的数据库特定表示。它会被视为DAO（我应该将我的课程命名为MeasurementDAO）吗？
答案 0 :(得分：2)
你得到的绝对正确，将DBEntry DAO保持为独立的实体总是更好。
让我们考虑一下memory，
假设您的课程Measurement需要保存在Database中，以后需要10个更多其他属性，但实际上您不会在整个应用中使用它们，那么如果您对于两者都使用相同的模型然后它会消耗一些未使用的内存，在这种情况下，您可以访问它，显然在这种情况下创建单独的实体是明显且优选的解决方案。
始终为可伸缩性设计应用程序，今天id是唯一的属性，明天您可能必须添加一些其他附加属性，仅用于仅在Database中保存。这种设计在将来可以方便。
答案 1 :(得分：0)
我的个人观点 - 维护一个单独的类（无论它是否使用继承或组合）的额外努力值得吗？ ID属性只是一个属性 - 我没有明确地将它看作是与数据库耦合的东西（它不像你将与数据库相关的依赖项拉入你的Measurement类）。
如果是我，我只会更新Measurement类 - 此外，如果您要在其他任何地方读/写它，您可能还需要ID，这意味着您仍然会通过它到处都是，无论如何都不会直接使用底层的测量类。
是的，我同意 - 你所谈论的课程听起来不像DAO - 更像是DTO。