将我的 POJO 保存到 Jackrabbit JCR 的最佳方法是什么? [英] What is the best way to save my POJOs into Jackrabbit JCR?
问题描述
在 Jackrabbit 中，我体验了两种将我的 POJO 保存到存储库节点以存储在 Jackrabbit JCR 中的方法:
In Jackrabbit I have experienced two ways to save my POJOs into repository nodes for storage in the Jackrabbit JCR:
- 编写我自己的层和
- 使用 Apache Graffito
虽然非常灵活，但事实证明，编写自己的代码既费时又费力(必须编写和运行许多丑陋的自动化测试).
Writing my own code has proven time consuming and labor intensive (had to write and run a lot of ugly automated tests) though quite flexible.
使用 Graffito 令人失望，因为它似乎是一个死"的项目在 2006 年停滞不前
Using Graffito has been a disappointment because it seems to be a "dead" project stuck in 2006
有哪些更好的选择?
推荐答案
另一种选择是完全跳过 OCM 框架并简单地使用 javax.jcr.Node 作为一个非常灵活的 DAO 本身.OCM 框架存在的根本原因是因为使用 RDBMS，您需要从对象到关系模型的映射.有了 JCR，它已经非常面向对象(节点 ~= 对象)，这个根本原因就消失了.剩下的就是通过 DAO，你可以限制你的程序员在他们的代码中可以访问的内容(包括自动完成的帮助).但是这种方法并没有真正利用 JCR 概念，这意味着无模式和灵活的编程.直接在您的代码中使用 JCR API 是遵循该概念的最佳方式.
Another alternative is to completely skip an OCM framework and simply use javax.jcr.Node as a very flexible DAO itself. The fundamental reason why OCM frameworks exist is because with RDBMS you need a mapping from objects to the relational model. With JCR, which is already very object-oriented (node ~= object), this underlying reason is gone. What is left is that with DAOs you can restrict what your programmers can access in their code (incl. the help of autocompletion). But this approach does not really leverage the JCR concept, which means schema-free and flexible programming. Using the JCR API directly in your code is the best way to follow that concept.
想象一下，您想在应用程序生命周期的后期向现有节点/对象添加新属性 - 对于 OCM 框架，您还必须对其进行修改并确保它仍然正常工作.通过直接访问节点，它只是一个单一的变化点.我知道，这是解决打字错误的好方法，例如.属性名称；但是这种担心并没有得到现实的支持，因为在大多数情况下，当您测试应用程序时，您会很快注意到拼写错误或不匹配的名称.一个好的解决方案是为公共节点或属性名称使用字符串常量，如果您在它们之间公开 JCR API，即使作为 API 的一部分也是如此.这仍然使您可以灵活地快速添加新属性，而无需采用 OCM 层.
Imagine you want to add a new property to an existing node/object later in the life of your application - with an OCM framework you have to modify it as well and make sure it still works properly. With direct access to nodes it is simply a single point of change. I know, this is a good way to get problems with typos in eg. property names; but this fear is not really backed by reality, since you will in most cases very quickly notice typos or non-matching names when you test your application. A good solution is to use string constants for the common node or property names, even as part of your APIs if you expose the JCR API across them. This still gives you the flexibility to quickly add new properties without having to adopt OCM layers.
对于允许的内容或强制性的内容(即半模式")有一些限制，您可以使用节点类型和混合(自 JCR 2.0 起，您还可以更改现有内容的节点类型):因此您可以完全在存储库级别处理此问题，不必关心应用程序代码中的类型和约束 - 除了捕获异常 ;-)
For having some constraints on what is allowed or what is mandatory (ie. "semi-schema") you can use node types and mixins (since JCR 2.0 you can also change the node type for existing content): thus you can handle this completely on the repository level and don't have to care about typing and constraints inside your application code - apart from catching the exceptions ;-)
当然，这个选择取决于您的要求和个人喜好.
But, of course, this choice depends on your requirements and personal preferences.
这篇关于将我的 POJO 保存到 Jackrabbit JCR 的最佳方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
