CUBA平臺使用感想 - 架構師角度

使用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名稱就是來源於古巴島，漂亮的地方 ^^