为什么要对象化而不是 JDO？
我正在接近Gwt + Gae 的世界。
我的基本需求是通过 Gwt-Rpc 线路发送我的实体类，而不将它们复制到 DTO 中。
Objectify 承诺能够很好地做到这一点。 它声称它将隐藏所有“Jdo 复杂性”。
我从未使用过 Jpa 或 Jdo 技术。 所有的复杂性都在哪里？
我的意思是，您能为我提供一些有关 JDO 中复杂任务的简单示例吗？Objectify 使这些任务变得微不足道？
也许是关系？
I am approaching to Gwt + Gae world.
My essential need is to send over the Gwt-Rpc wire my Entity classes, without duplicating them into DTOs.
Objectify promise to do that pretty well.
It claims it will hide all the "Jdo complexity".
I never worked with Jpa or Jdo technologies.
Where's all the complexity?
I mean, can you provide me some simple examples about complex tasks in JDO, made trivial by Objectify?
Maybe relationships?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 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 中打破什么:)
I think JDO/JPA are easy to play with on "Hello World" level. But it changes as soon as you need something more real such as composite keys, multiply relationships between entities and etc. JDO GAE implementation is quite complex and hard to grasp for beginners, partly due to unsupported features, workarounds and extensions. JDO is designed to work "everywhere", which means it is highly abstracted and very general in its nature. Great for portability, but it also means that it might not be a perfect match for a specific engine like GAE with its quite unique datastore. The Datanucleus/JDO/JPA jars are quite big (~2.3 mb in total), while Objectify's jar is pretty small. JDO/JPA might perform class path scanning at startup to find and register your entities, which could add to the load time. The time spent would be proportional to the number of classes in your project.
As per example I think in terms of amount of code JDO/JPA sample will appear simpler than lots of DAO classes for Objectify, but in general, maintenance of Objectify code will be easier for an engineer because you don't need to walk through minefield thinking what you can break in JDO :)
JDO 复杂性的一个例子是查看一个实体可以处于多少种不同的状态。作为一开始可能会让人不知所措的示例，滚动到 此页面 并查看该状态图。 Objectify 不需要这样的状态图。
JDO 的另一个棘手部分是幕后发生的所有“魔法”，这有时会使调试变得困难。当然，这实际上并不是魔法，只是字节码重写，但这已经够棘手的了。
最后，JDO 是一个通用 API。它旨在与对象存储、SQL 数据库以及谁知道还有什么一起使用。有时很难看出某个 JDO 概念与数据存储区中实际发生的情况之间的联系。 Objectify 的 API 与数据存储区紧密结合，让您更容易理解正在发生的事情。
One example of JDO's complexity is seeing how many different states an entity can be in. As an example of how this can be overwhelming at first, scroll to the bottom of this page and look at that state diagram. Objectify does not need such a state diagram.
Another tricky part of JDO is all the 'magic' that happens behind the scenes, which sometimes made debugging difficult. Of course this is not actually magic, just bytecode rewriting, but that along is tricky enough.
Finally, JDO is a generic API. It is designed to work with object stores, SQL databases, and who knows what else. The connection between a certain JDO concept and what will actually be happening in the datastore is sometimes difficult to see. Objectify's API is closely aligned with the datastore, making it easier to understand what is going on.