JCR中的OCM或节点?

时间:2013-05-18 11:00:52

标签: content-management-system pojo jackrabbit jcr

我们正在开发基于JCR / Sling / JSP / Felix /等的CMS

到目前为止,我发现使用节点是非常直接和灵活的。但我担心的是,随着时间的推移,维护和管理可能会变得太难。

那么,投资使用OCM是明智的吗?它只是一层额外的复杂性吗?如果有的话,OCM的真正好处是什么?或者我们更好地坚持使用Nodes?

最后,如果我们要沿着这条路走下去,Jackrabbit OCM对我们来说是最好的选择吗?

谢谢。

1 个答案:

答案 0 :(得分:2)

根据我的个人经验,如果OCM是您项目的有用工具,我可以说这完全取决于您的情况。

使用OCM的真正问题(根据我的个人经验)是在存储库中现有持久数据(作为对象)中使用的类的定义发生了变化。例如:您发现有必要更改类的某些成员和方法以匹配功能更改。我的意思是存储库中持久化数据对象的类定义不再与实际类的定义匹配。当持久化数据保存到jcr存储库时,它通常以java在序列化方面理解的格式保存。这意味着当某些内容更改为已使用类的定义时,存储库中保存的数据将无法再由Java正确解释。此问题往往会导致复杂的部署,您需要将旧的持久数据对象转换为新的定义并将其再次保存在存储库中,以确保您仍然可以使用" old"但仍需要持久数据。

工作(在我看来)使用的框架允许直接将节点和节点属性映射到java对象(例如通过使用注释),反之亦然(将Java对象作为JCR保存到存储库) java成员字段是实际节点属性的节点)。这样你就可以坚持使用jcr(具有属性的节点)的数据表示,并且仍然可以将它们映射到java类的成员。

我之前在一个名为AEM(Adobe)的cms中使用了这样的框架,虽然我必须提到这是在OSGI环境中(但是原理仍然存在)。使用的框架基本上允许最大的灵活性,并将java对象持久化为JCR节点,反之亦然。因为它直接映射到jcr定义,所以类和成员中的代码更改只是更改注释,旧的持久化数据仍然可以使用而不需要太多努力。