使用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的时候会比较抵触，主要有这几个方面：
- 使用了不少xml，其中Spring bean的配置、view（EclipseLink的视图）的配置、REST service的配置、页面结构的配置等等，基本都是用xml来做。对于习惯了Spring boot的开发者来说，可能是会觉得比较麻烦。但是其实xml配置也有一个好处，就是配置都集中在xml文件里，而不会分散在各个包内。
- 使用了Vaadin框架作为前端页面实现。CUBA本身支持三种前端，包括基于Vaadin的web client，基于Swing的desktop client，还有基于Polymer的web portal。其中Vaadin和Swing都是用Java语言写的前端，只有Polymer是google的框架，使用的是纯前端的技术。Vaadin有个问题就是做样式调整需要后端人员配合，这样的话，纯前端人员使用上会觉得非常麻烦。
- CUBA提供了一个便于开发的Studio，使得开发的过程中需要在Studio和IDE环境之间频繁切换。这个对于老鸟来说，多少有点累赘。
然后站在架构师的角度，我再说说CUBA比较好的地方，最后再说我是怎么克服或者说理解CUBA的架构，才明白其实之前三点对CUBA讨厌的地方只是对这个框架不了解。
CUBA框架在架构上的优点，通过我这近一年的使用来看，有以下几个：
1. 功能组件化。在开发高度可定制化产品这篇文章中有提到，怎样做产品和客户化之间关系的管理，CUBA独特的组件化无疑是个最大的亮点。我们可以把通用功能，比如短信服务、消息队列机制、通用报表等等功能上不依赖具体客户化的模块做成CUBA组件。也可以把客户化功能，比如某某客户要求的一种特殊的数据类型导入或者某某某客户要求的对接某一特殊网络接口接入数据等非常不通用的功能也做成组件化。这样一来对于项目实施就会有两种思路：第一种是我们专注通用产品开发，而将客户化功能作为组件嵌入；另一种就是我们专注客户化开发，而将通用产品功能作为组件嵌入。这两种思路在平衡产品研发和客户化功能需求的时候可以按需选择，如果客户化功能不多，可以采用第一种方案，反之采取第二种方案。
2. 支持扩展。
- 支持Bean的扩展。CUBA平台由于基于Spring技术，所以带来了很好的可扩展性。首先是Spring的Bean，我们只需要继承并Override Bean的方法然后在Spring Context注册同样名称的Bean就可以替换CUBA提供的Bean，所以，任何CUBA默认提供的功能都可以做客户化定制开发。比如FileStorage，目前CUBA只提供对于目录和对于AmazonS3的文件存储方案，但是如果我们需要使用FTP作为文件存储呢，很简单，只要实现CUBA提供的FileStorageAPI的接口，然后在Spring.xml里面配置用你的实现类替换默认的类就行。
- 支持页面扩展。这里就是用xml配置页面的好处了，之前也接触过一些开发平台，但是有个问题就是平台提供的一些页面，没法做扩展。比如用户编辑页面，需要增加用户信息的时候只能自己开发，平台提供的默认页面就成了鸡肋。但是如果需要修改CUBA自带页面设计的组件或者结构，或者想扩展自己开发的页面，只需要在页面配置的xml文件里“继承”一下想要扩展的页面就好了。然后可以在新的xml“重写”或者添加新的页面元素。这一点是很多框架平台做不到的。
- 支持数据库实体扩展。大家可能觉得奇怪，实体扩展不就是类继承么，有什么好提的？如果只是类的继承确实没什么好提的，但是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名称就是来源于古巴岛，漂亮的地方 ^^
