Martin Fowler談CMS系統中編輯-釋出模組的分離

acid-free發表於2012-08-03

Martin Fowler談CMS系統中編輯-釋出模組的分離

在過去一年左右跟ThoughtWorks專案團隊的談話中,內容管理系統(CMS,Content Management System)日漸增長的影響成了老生常談。它們並非我們通常認為的那麼有用,事實上有個明顯的標誌說明它們正在被濫用——它們的使用已經超出了主要用途,以至於妨害了整體的發展。

除了其他瑣碎的問題之外,一個通病是它們都只保留每篇內容[1]的一個版本。這個版本會作為建立內容中的一部分來編輯,並向讀者釋出(通常在某些狀態更改標記上體現)。

[1] 注:作者在原文中使用article來指代CMS系統管理的任何形式的內容。在譯文中並未採用“文章”來對應,而是直接使用“內容”來替代。

只保留資料的單個版本這種思路很常見。它是支撐標準化有關概念的基本原則。企業應用架構師通常會盡力保證關鍵資料只有唯一一個權威版本。

但這個方案對CMS系統來說有個明顯的缺陷——編輯和釋出的資料訪問模式差異很大。編輯過程只涉及到一小群人頻繁地訪問這份內容,進行讀取和更新。釋出則涉及到非常多的人(我們所期望的)來訪問該內容,但都是讀取。我們會在已釋出的內容上做一些編輯操作來勘正錯誤,但與讀取相比,這種操作要少很多,而且是由一群嚴格控制的人來完成。

在這兩種不同的訪問路徑中,一些CMS系統保留著這些內容的不同版本,並由一些相對獨立的模組來控制。編輯模組是為了頻繁的更新而設立,它為編輯內容、記錄修改和監測編輯工作流程提供支援。當要釋出內容時,內容會通過釋出模組複製過去。

流程圖

釋出模組會將內容作為普遍只讀、極少更新的資料來對待,並只能由編輯模組來更新。因此釋出模組被設計成了向大批讀者提供內容服務。它起碼涉及到了資料儲存的另一種配置。釋出模組可以在叢集中的多個節點隨意複製,而通常編輯模組集中在單個節點更合適。在不同的資料儲存技術上也存在爭論,這些技術允許每個模組針對其訪問模式採用恰當的方式。

內容也可以儲存為不同格式。通常內容會按某種格式編輯,而按另一種格式釋出,比如按markdown格式編輯而按html格式釋出。既然如此,編輯模組會將內容儲存為markdown格式,而釋出模組會儲存為html。釋出模組也可以針對其儲存的版本做一些頁面格式調整。所以如果要給內容加個靜態化的頭,你可以在內容釋出時加在所儲存內容的html上,而不用每次讀取時都再次調整格式[2]

[2] 注:這意味著對頭進行的任何修改都會要求重新生成已釋出的內容。通常,這跟每次讀取時都進行頁面格式調整相比不算是問題。

將這些模組分離也有益於編輯的流程。通常,人們要在將內容釋出出去之前預覽一下所做的修改。有了分離後這非常容易,因為你可以先通過內部發布模組釋出到待發布空間。這樣就可以巧妙地處理那些確認究竟要從儲存中釋出哪些內容的複雜邏輯。

使用者釋出內容使得這種方法有點捉襟見肘。wiki的內容完全由使用者釋出,比起精心策劃的網站,它的編輯群要更大並控制得要寬鬆一些。類似地,讀者評論來自更大範圍的人群。但即使是使用者釋出內容,讀者也要比作者多得多,這樣將處理更新和提供已釋出頁面分離開來也就有意義了。

那些使用領先的支援編輯-釋出分離的系統的團隊發現它能很好地發揮作用,而大多數使用的工具不支援編輯-釋出分離的團隊則認為這種分離可以帶來改進。如果你正在評估一個CMS系統,或正在構建一個來滿足自己的需求,你一定要考慮將編輯-釋出分離作為系統要具備的一個重要功能。


原文連結EditingPublishingSeparation

作者簡介:Martin Fowler是ThoughtWorks的首席科學家,也是當今世界軟體開發領域最具影響力的五位大師之一。作為敏捷軟體開發方法的早期開拓者,他極大地改變了人們對軟體開發流程的認識,並對軟體開發業界產生了革命性的影響。

譯者簡介:武海峰(ID:acid-free),開源軟體擁護者;關注領域為Linux系統構建及部署,Ruby on Rails開發和移動應用開發。轉載請註明出處。

相關文章