2013-05-18 84 views
2

我們正在開發基於JCR/Sling/JSP/Felix /等的CMS。OCM或JCR中的節點?

我發現至今使用的節點是非常簡單和靈活。但是我擔心隨着時間的推移,維護和管理可能變得非常困難。

那麼,是不是明智的投資使用OCM?會不會僅僅是一個額外的複雜層?如果有OCM,真正的好處是什麼?或者,我們更好地堅持節點而不是?

最後,是兔崽子OCM最好的選擇對我們來說,如果我們要走這條路?

謝謝。

回答

2

就我個人的經驗,我可以說這severly取決於你的情況,如果OCM是爲您的項目或不是一個有用的工具。

使用OCM(以我個人經驗),真正的問題是,當在現有使用的類定義持久數據(對象)中的資源已經變化。例如:您發現有必要更改類的某些成員和方法以匹配功能更改。這意味着存儲庫中持久化數據對象的類定義不再與實際類的定義相匹配。當一個持久化數據被保存到jcr倉庫中時,它通常以java可以識別的序列化格式保存。這意味着,如果某些內容更改爲所用類的定義,則存儲庫中保存的數據將不能再由java正確解釋。此問題往往會導致部署複雜,您需要將舊的持久數據對象轉換爲新定義並將其再次保存到存儲庫中,以確保仍然可以使用「舊」數據對象,但仍然需要持久數據。

什麼工作(在我看來)是使用一個框架,允許將節點和節點屬性直接映射到java對象(例如通過使用註釋),反之亦然(將java對象作爲一個持久存儲庫其中java成員字段是實際節點屬性的JCR節點)。通過這種方式,您可以堅持jcr(具有屬性的節點)的數據表示,並且仍然可以將它們映射到java類的成員。我曾經在一個名爲AEM(Adobe)的cms中使用過這樣的框架,但我必須提到這是在OSGI上下文中(但prinicipe仍然存在)。使用的框架基本上允許最大的靈活性,並將java對象作爲JCR節點持續存在,反之亦然。因爲它直接映射到jcr定義,因此類和成員中的代碼更改只是更改註釋,而舊的持久數據仍然可以毫無用處地使用。

+0

我們期待我們的數據結構,隨着時間的推移。這是我們選擇JCR進行存儲的主要原因之一。聽起來像OCM最初會提供便利,但可能會阻礙線下的靈活性。我認爲你很有發現。 我會看看AEM。謝謝。 – hewell

+0

請注意,我所說的框架與AEM分離,它被稱爲slice(來自cognify),但在AEM(或任何其他使用jcr作爲後端的OSGI環境)中插入很好 – 3xil3

+0

現在有意義。 :)我沒有時間深入研究它。但它看起來就是我們所需要的。非常感謝你! – hewell

相關問題