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

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM