Content management system OCM还是JCR中的节点？

我们正在开发一个基于JCR/Sling/JSP/Felix/etc的CMS

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

那么，投资使用OCM明智吗？这仅仅是一种额外的复杂性吗？OCM的真正好处是什么？或者我们最好还是坚持使用节点

最后，如果我们要走这条路，Jackrabbit OCM是我们的最佳选择吗

---

谢谢。

根据我个人的经验，如果OCM对您的项目有用与否，我可以说这完全取决于您的情况

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

在我看来，有效的方法是使用一个框架，允许将节点和节点属性直接映射到java对象（例如，通过使用注释），反之亦然（将java对象作为JCR节点持久化到存储库中，其中java成员字段是实际的节点属性）。这样，您就可以坚持jcr（具有属性的节点）的数据表示，并且仍然可以将它们映射到java类的成员

---

我以前在名为AEM（Adobe的）的cms中使用过类似的框架，尽管我必须提到这是在OSGI上下文中使用的（但prinicipe仍然有效）。所使用的框架基本上允许最大的灵活性，并将java对象持久化为JCR节点，反之亦然。因为它直接映射到jcr定义，类和成员中的代码更改只是更改注释，旧的持久化数据仍然可以使用，无需付出太多努力。

我们希望我们的数据结构会随着时间的推移而发展。这是我们选择JCR作为存储的主要原因之一。听起来OCM一开始会提供便利，但可能会妨碍后续的灵活性。我想你是对的。我来看看AEM。谢谢。请注意，我所说的框架与AEM是分开的，它被称为slice（来自cognify），但在AEM（或任何其他使用jcr作为后端的OSGI环境）中插入了现在有意义的great我还没来得及深入研究。但这看起来正是我们需要的。非常感谢你！JCR存储库的一个强大好处是，模式/结构可以随时更改，允许您的应用程序随着需求/需求的变化而不断发展。使用OCM层将限制这种灵活性。这在某些应用程序中很好，但在其他应用程序中却非常不受欢迎。