我正在接近 Gwt + Gae 世界。
我的基本需求是通过 Gwt-Rpc 线路发送我的实体类，而不是将它们复制到 DTO 中。
Objectify 承诺会做得很好。 它声称它将隐藏所有“Jdo 复杂性”。
我从未使用过 Jpa 或 Jdo 技术。 复杂性在哪里？
我的意思是，您能否提供一些关于 JDO 中复杂任务的简单示例，这些示例被 Objectify 简化了？
也许是关系？
【问题讨论】：
标签： google-app-engine jdo objectify
我认为 JDO/JPA 在“Hello World”级别上很容易玩。但是，一旦您需要更真实的东西（例如复合键、实体之间的乘法关系等），它就会发生变化。JDO GAE 实现对于初学者来说非常复杂且难以掌握，部分原因是不支持的功能、变通方法和扩展。 JDO 旨在“无处不在”地工作，这意味着它在本质上是高度抽象且非常通用的。非常适合可移植性，但这也意味着它可能不适合像 GAE 这样具有非常独特的数据存储的特定引擎。 Datanucleus/JDO/JPA jar 非常大（总共约 2.3 mb），而 Objectify 的 jar 非常小。 JDO/JPA 可能会在启动时执行类路径扫描以查找和注册您的实体，这可能会增加加载时间。花费的时间与项目中的课程数量成正比。
根据示例，我认为就代码量而言，JDO/JPA 示例会出现比 Objectify 的许多 DAO 类更简单，但总的来说，Objectify 代码的维护对于工程师来说会更容易因为你不需要走过雷区去思考你可以在 JDO 中打破什么:)
【讨论】：
JDO 复杂性的一个例子是查看一个实体可以处于多少种不同的状态。作为一个一开始可能会让人不知所措的例子，请滚动到this page 的底部并查看该状态图。 Objectify 不需要这样的状态图。
JDO 的另一个棘手部分是在幕后发生的所有“魔法”，这有时会使调试变得困难。当然这实际上并不是魔术，只是字节码重写，但这已经够棘手了。
最后，JDO 是一个通用 API。它被设计为与对象存储、SQL 数据库以及谁知道还有什么一起工作。某个 JDO 概念与数据存储中实际发生的事情之间的联系有时很难看出。 Objectify 的 API 与数据存储区紧密结合，更容易理解发生了什么。
【讨论】：