什么是“低风险”? JDO还是JPA之间选择?

发布于 2024-09-27 12:53:30 字数 819 浏览 2 评论 0原文

不要将其作为其他问题的重复项来关闭,因为我没有问同样的事情。他们也一岁左右了。也就是说,请参阅以下链接:

http://db.apache.org/jdo/jdo_v_jpa.html< /a>

http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html< /a>

http://www.datanucleus.org/products/accessplatform/persistence_api.html< /a>

看来 JPA 是大供应商支持的“流行”选择(如果可以的话,他们喜欢把你搞砸)。 看来 JDO 是更成熟、看似更优越的选择,应该得到更多 OSS 社区的支持。 (但是确实如此吗?)

那么低风险容忍度组织应该做什么?从一个到另一个的难度是否相同?此时,其中一个已经开始超越另一个了吗?另外,仅仅因为我们当前使用它,Hibernate 是否会限制您只能使用 JPA?如果是的话,最流行的 JDO 实现是什么?

Do not close this as a duplicate of other questions because I'm not asking the same thing. They're also about a year old. That said, see these links:

http://db.apache.org/jdo/jdo_v_jpa.html

http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html

http://www.datanucleus.org/products/accessplatform/persistence_api.html

It seems JPA is the "popular" choice backed by the big vendors (who love to screw you over if they can).
It seems JDO is the more mature, seemingly superior choice which should enjoy more OSS community backing. (But does it?)

So what's a low-risk tolerance organization supposed to do? Is the difficulty of going from one to the other about the same? Has one started to emerge above the other at this point? Also, only because we currently use it, does Hibernate limit you to JPA-only? If so what is the most popular JDO implementation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

累赘 2024-10-04 12:53:30

@Crusader - 是什么让你认为 SO 上的任何人都比你拥有更好的水晶球?

那么低风险容忍度组织应该做什么?

选择确定为低风险解决方案的替代方案。它如何确定哪种解决方案风险最小尚不清楚……但我不认为提出这样的要求是有效的风险评估程序。

另一点是,当 JPA 是“赢家”时选择 JDO(反之亦然)可能不会在短期或长期内杀死您的项目。做出错误选择的后果很可能仅限于更高的员工培训成本,并且被困在基础 ORM 平台上,该平台的开发停滞不前,支持费用也越来越昂贵。 [我会通过选择开源 ORM 平台来保护自己免受后者的影响……无论如何。]

从一个到另一个的难度是否相同?

可能是的。尤其是当您考虑数据迁移问题时。

此时,其中一个已经开始超越另一个了吗?

如今,JPA 似乎占据主导地位。 JDO 人员会说他们的方法在技术上更优越,但这不是重点。

此外,仅仅因为我们当前使用它,Hibernate 是否会限制您只能使用 JPA?

JPA 加上 Hibernate 特定的扩展。当然,Hibernate 也不支持 JDO,而且可能永远不会支持。

如果是的话,最流行的 JDO 实现是什么?

经过。

@Crusader - what makes you think that anyone on SO has a better crystal ball than you do?

So what's a low-risk tolerance organization supposed to do?

Pick the alternative that it determines to be the low risk solution. How it determines what solution has the least risk is ... unclear ... but I don't think that asking SO is a valid risk assessment procedure.

The other point is that choosing JDO when JPA is the "winner" (or vice versa) probably won't kill your project in the short or long term. The consequences of making the wrong choice are most likely limited to greater staff training costs, and being stuck with base ORM platform where development has stagnated and support is increasingly expensive. [I'd protect myself against the latter by picking an open source ORM platform ... either way.]

Is the difficulty of going from one to the other about the same?

Probably yes. Especially when you consider data migration issues.

Has one started to emerge above the other at this point?

JPA seems to dominate these days. The JDO folks would say that their way is technically superior, but that's not the point.

Also, only because we currently use it, does Hibernate limit you to JPA-only?

JPA plus Hibernate-specific extensions. Certainly Hibernate does nor support JDO and it probably never could.

If so what is the most popular JDO implementation?

Pass.

空心↖ 2024-10-04 12:53:30

如果您使用轻量级依赖注入和 ORM 包装框架(例如开源 exPOJO),它可以让您完全绕过这个问题。您的主要代码库仍然完全不知道底层持久性接口/技术(JDO、当前支持的 Hibernate 实现、即将推出的 JPA - 想伸出援助之手吗?)。

根据 Chris Richardson 的优秀著作《POJOs in Action》,所有持久性技术特定代码都封装在存储库和服务类中,并使用他在书中讨论的“公开域模型”模式进行公开 - 事实证明,这非常出色且最高效我曾经使用过的方法。

使用 exPOJO,您的 99% 的代码仍然可以在 JDO、JPA、Hibernate 之间轻松、即时地移植,而且您还可以获得极其轻量且非常简单的依赖项注入(不需要注释或 XML)作为额外的好处。

它带有自己的极其轻量且易于使用的 servlet 过滤器,可以提供“视图中的开放会话/持久性管理器/实体管理器”,而无需 XML 地狱。每个 HTTP 请求都会自动附加到 ModelExposer 对象,该对象提供对存储库和服务组件的便捷访问,从而允许对对象进行通用访问。

exPOJO 位于 http://www.expojo.com - 是的,好吧,我写的,所以我有点偏见 = ]

If you use a lightweight dependency injection and ORM wrapping framework like the open source exPOJO it allows you to bypass that question altogether. Your main code base remains completely agnostic of the underlying persistence interface/technology (JDO, Hibernate implementations currently supported, JPA on the way - like to lend a hand?).

All persistence technology specific code is encapsulated within Repository and Service classes as per Chris Richardson's excellent book "POJOs in Action" and exposed using the "exposed domain model" pattern he discusses in the book - which turns out to be pretty awesome and the most productive approach I've ever used.

Using exPOJO 99% of your code remains gloriously and instantly portable between JDO, JPA, Hibernate plus you get extremely lightweight and very simple dependency injection (no annotations or XML required) as an added bonus.

It comes with it's own extremely lightweight and easy to use servlet filter that can provide "open session/persistence manager/entity manager in view" without the XML hell. Each HTTP request is automatically attached to a ModelExposer object that provides convenient access to the repository and service components that allow generic access to your objects.

exPOJO is at http://www.expojo.com - yeah ok, I wrote it so I am biased slightly =]

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文