使用CUBA.Platform快要有一年了，從最初的難以理解和比較抵觸，到現在真的有點喜歡這個框架，中間也確實經歷了不少事情。

先簡單介紹一下CUBA平臺，這個框架是基於Spring的一個Java開發框架，目前的版本採用典型的三層架構，ORM層使用的是EclipseLink，中介軟體層使用的是Spring，展示層使用的是Vaadin（web client），Swing（desktop client）和Polymer（web portal）。所以其核心還是以Spring為中心的Java EE框架。

由於之前我用的Hibernate+Spring boot+Angular的技術架構，所以剛開始接觸CUBA的時候會比較抵觸，主要有這幾個方面：

1. 使用了不少xml，其中Spring bean的配置、view（EclipseLink的檢視）的配置、REST service的配置、頁面結構的配置等等，基本都是用xml來做。對於習慣了Spring boot的開發者來說，可能是會覺得比較麻煩。但是其實xml配置也有一個好處，就是配置都集中在xml檔案裡，而不會分散在各個包內。
2. 使用了Vaadin框架作為前端頁面實現。CUBA本身支援三種前端，包括基於Vaadin的web client，基於Swing的desktop client，還有基於Polymer的web portal。其中Vaadin和Swing都是用Java語言寫的前端，只有Polymer是google的框架，使用的是純前端的技術。Vaadin有個問題就是做樣式調整需要後端人員配合，這樣的話，純前端人員使用上會覺得非常麻煩。
3. CUBA提供了一個便於開發的Studio，使得開發的過程中需要在Studio和IDE環境之間頻繁切換。這個對於老鳥來說，多少有點累贅。

然後站在架構師的角度，我再說說CUBA比較好的地方，最後再說我是怎麼克服或者說理解CUBA的架構，才明白其實之前三點對CUBA討厭的地方只是對這個框架不瞭解。

CUBA框架在架構上的優點，通過我這近一年的使用來看，有以下幾個：

1. 功能元件化。在開發高度可定製化產品這篇文章中有提到，怎樣做產品和客戶化之間關係的管理，CUBA獨特的元件化無疑是個最大的亮點。我們可以把通用功能，比如簡訊服務、訊息佇列機制、通用報表等等功能上不依賴具體客戶化的模組做成CUBA元件。也可以把客戶化功能，比如某某客戶要求的一種特殊的資料型別匯入或者某某某客戶要求的對接某一特殊網路介面接入資料等非常不通用的功能也做成元件化。這樣一來對於專案實施就會有兩種思路：第一種是我們專注通用產品開發，而將客戶化功能作為元件嵌入；另一種就是我們專注客戶化開發，而將通用產品功能作為元件嵌入。這兩種思路在平衡產品研發和客戶化功能需求的時候可以按需選擇，如果客戶化功能不多，可以採用第一種方案，反之採取第二種方案。

2. 支援擴充套件。

1. 支援Bean的擴充套件。CUBA平臺由於基於Spring技術，所以帶來了很好的可擴充套件性。首先是Spring的Bean，我們只需要繼承並Override Bean的方法然後在Spring Context註冊同樣名稱的Bean就可以替換CUBA提供的Bean，所以，任何CUBA預設提供的功能都可以做客戶化定製開發。比如FileStorage，目前CUBA只提供對於目錄和對於AmazonS3的檔案儲存方案，但是如果我們需要使用FTP作為檔案儲存呢，很簡單，只要實現CUBA提供的FileStorageAPI的介面，然後在Spring.xml裡面配置用你的實現類替換預設的類就行。
2. 支援頁面擴充套件。這裡就是用xml配置頁面的好處了，之前也接觸過一些開發平臺，但是有個問題就是平臺提供的一些頁面，沒法做擴充套件。比如使用者編輯頁面，需要增加使用者資訊的時候只能自己開發，平臺提供的預設頁面就成了雞肋。但是如果需要修改CUBA自帶頁面設計的元件或者結構，或者想擴充套件自己開發的頁面，只需要在頁面配置的xml檔案裡“繼承”一下想要擴充套件的頁面就好了。然後可以在新的xml“重寫”或者新增新的頁面元素。這一點是很多框架平臺做不到的。
3. 支援資料庫實體擴充套件。大家可能覺得奇怪，實體擴充套件不就是類繼承麼，有什麼好提的？如果只是類的繼承確實沒什麼好提的，但是CUBA提供的不只是繼承，還有替換！有沒有遇到過這樣的情況，使用開發平臺的時候，比如平臺提供的User實體，可能你需要新增一些其他的屬性，比如電話號碼，公司職位等，但是平臺預設提供的User並不支援，你就得開發一個UserExt實體，擴充套件User，然後在UserExt裡面一對一的關聯User實體。這無疑給開發帶來了麻煩，因為需要關聯查詢。但是CUBA提供實體類擴充套件替換，就是說在CUBA裡面，你的UserExt是直接擴充套件User表，並且全域性替換掉User實體，這樣你可以直接在CUBA的User表裡面新增欄位，而不需要使用關聯查詢了，任何JPQL訪問User實體的時候都會在底層被替換成訪問UserExt實體，這些都是平臺幫我們做的。我們使用的時候雖然是UserExt，但是跟用User沒區別了。

3. 安全子系統

預設提供了整合LDAP的方案，Windos login可以直接使用統一單點登入。除此之外，CUBA系統本身也支援基於Http的單點登入，只需要簡單的配置就可以。雖然目前CUBA的單點登入還不支援外部系統，不過這塊可以通過客戶化開發解決。在CUBA的論壇上也提供了基於SAML協議的SSO方案。在REST API安全性方面，CUBA預設提供三種方式：全域性匿名，全域性需要認證，部分API匿名，以滿足多樣化的API請求環境。

4. 方便的REST API開發

CUBA開發的系統本身就帶了很多預製的REST API，包括執行JPQL、查詢實體、提供授權token等。除此之外，利用CUBA開發REST API也是非常的簡單。用SpringMVC已經很簡單了，只需要自己寫RestController，RequestMapping等，但是用CUBA，簡單到只需要寫Service！實體的增刪查改只需要建立實體類就搞定了。其他service的REST API，只需要寫好service的方法，在Studio裡面勾選需要支援REST API的選項（不用studio的話，自己把service新增到rest-service.xml就行）就好了！同時支援GET跟POST方法。這樣的話，開發API的腳手架程式碼也都可以省去。如果採用前後端分離的開發方法，後端工程師只需要關注業務邏輯的開發。

5. 部署多樣化

通過CUBA Studio很方便在開發環境進行部署，用Studio啟動專案之後，會在專案的根目錄建立一個deploy目錄，裡面會有全套的Tomcat以及部署好的應用服務。想偷懶的話，直接把這個tomcat丟到伺服器上，啟動服務就行。除此之外，還支援UberJar方案，前後端分離部署方案，前後端分別做叢集方案等，以及支援Heroku等雲部署方案，docker方案，不贅述了，需要了解的可以參考CUBA官方文件。

最後再說一下本文開頭的幾個起初覺得CUBA不是很好的地方：

1.使用很多xml。其實從開發人員使用的角度，如果不是老鳥，是感受不到太多xml的，除了screen.xml，這個需要開發人員在寫頁面元素的時候會用到。很多xml的配置在使用CUBA Studio的過程中它會自動幫我們修改和配置的。但是CUBA用xml比較多還有另外一個原因，它的xml提供了更多的功能，通過xml這個紐帶，連線了Studio和CUBA，CUBA和Spring，正是因為xml的集中配置功能，Studio才能很好的幫助管理專案，並進行自動化配置。

2.使用Vaadin的情況。其實CUBA的初衷，並不是用Vaadin來做終端使用者的UI，終端使用者的UI是要用portal來做的，portal是基於Polymer的自適應前端框架，可以很好的適配不同解析度的客戶端，從桌面電腦到手機。那Vaadin客戶端是做什麼用的呢？Vaadin是用來開發給內部人員使用的管理介面，不要求頁面展現多麼炫酷，而追求顯示更多的內容，更合理的操作。比如一個典型的場景就是計程車排程系統，乘客和司機會通過手機端訪問portal展現的頁面，而計程車公司的排程人員會訪問Vaadin開發的排程頁面。這種情況下，開發人員不需要對Vaadin的樣式做太多修改，甚至使用預設主題就行，只需要能展示清晰、有條理的資料給管理人員即可。另外，CUBA將來也不單單是支援Polymer前端portal，也會支援基於React的前端技術，也有可能支援Angular前端，但是Vaadin還是作為主要的功能前端技術選型，因為Vaadin能很好的跟後臺整合開發，對快速實現業務功能提供了很好的支援，同時通過Vaadin的websocket技術，對前端安全也增加了一份保障。

3.Studio的情況，通過上面的介紹大家也應該知道了，studio可以幫我們完成很多腳手架程式碼，並且對於初學者來說，是個非常好的起點。但是，是需要但是一下的，CUBA的下一步動作是更多的免費，所以Studio很可能會變成一個完全收費的產品，不過不用擔心，在免費領域CUBA會提供CLI和IDEA+CUBA外掛的方式提供服務，對於喜歡黑螢幕的老鳥，可以直接使用CLI，對新人可以選擇IDEA加CUBA外掛的方式，或者選擇購買Studio（一年300多美金，真不貴）。所以從支援開發者這點來說，CUBA的工具和服務是貫穿開發過程始終的，能在專案的各個環節：啟動、開發、測試、部署都提供支援。這一點很多開發平臺是做不到的，有的作為程式碼生成器可能就是第一次提供給你程式碼，後來全靠手工自己寫了。

所以從架構師的角度看，CUBA採取了經典的三層架構，但是在客戶端層做了多樣化前端技術支援，並且提供開發全生命週期的工具支援。總的來看，是非常不錯的選擇。

ps，CUBA名稱就是來源於古巴島，漂亮的地方 ^^