cuba.platform_CUBA Platform 6.3的新增功能

cuba.platform

我们很自豪地宣布新版本的CUBA平台和Studio全面上市！
也许这是有史以来功能最丰富的平台版本之一–在各个级别上都有重要的变化：体系结构，可扩展性，API可用性和性能。

本文介绍了该平台的主要增强功能。发行说明中提供了完整的更改列表：
Platform 6.3发行说明
Studio 6.3发行说明

应用组件

如您所知，平台始终具有功能分解的机制：一方面，平台本身被拆分为核心和附加组件，另一方面，具有创建扩展项目的能力。扩展机制受到限制，因为它只能在垂直方向上工作–您可以为一个基础项目创建许多扩展，但不能创建类似于CUBA Reporting或BPM的加载项与其他加载项组合在最终应用程序中使用，并在其他项目中重复使用。

现在，通过引入应用程序组件的概念解决了该问题。使用应用程序组件，您可以将大型应用程序分解为一组功能模块，并将它们开发为单独的项目。此外，这些模块可以重复使用–您可以将它们包含在不同的应用程序中，就像使用CUBA高级附加组件一样。

例如，在出租车管理应用程序中，组件的结构可以如下：

应用组件

在这里，CUBA，报告和全文搜索是平台提供的组件。信用卡付款和定价是可重用的组件，可在不同的应用程序中使用；驱动程序工资包含仅提供给某些客户的可选功能。这种可选的依赖性意味着您不仅可以在开发中，而且可以在部署阶段将应用程序组件包含在应用程序中。

实际上，一个应用程序组件（或应用程序组件）只是一个公开一些有关其自身信息的应用程序。有关模块，配置属性和组件工件的信息包含在一个特殊文件中：app-component.xml; 特殊的JAR清单条目用于自动发现类路径中的组件。应用程序组件也可以看作是全栈库：它们提供所有级别的功能，包括实体，数据库DDL脚本，中间件服务，UI屏幕甚至CSS主题。

如果要使其成为组件，Studio会为当前项目自动生成app-component.xml。只需使用“项目属性”选项卡上的链接。为了在应用程序中使用组件，请编辑项目属性，然后将该组件添加到“自定义组件”列表中。

您可以在文档中看到创建和使用应用程序组件的示例。

支持多个数据存储

到目前为止，平台机制只能与为应用程序选择的单个数据库一起使用。您可以直接通过JDBC或其他连接使用其他数据源，但是它太复杂了，无法在标准UI组件中显示和编辑此类“外部”数据。

CUBA 6.3中实现的数据存储概念旨在解决使用相同的标准平台机制（例如，可感知数据的可视组件）在单个应用程序中处理来自不同来源的数据的问题。数据存储实际上是具有几种用于加载和保存实体的方法的接口。该平台当前包含此接口的一种实现，允许通过ORM层使用关系数据库。您可以在项目中创建自己的数据存储实现，例如，与NoSQL数据库，内存网格或与其他应用程序集成。

当您在应用程序中使用多个数据存储时，其数据模型将包含映射到来自不同位置的数据的实体。如果数据存储是RDBMS，则实体将被注释为JPA持久类。否则，实体将是非持久性的，自定义数据存储实现负责将实体映射到数据。一个应用程序将始终具有一个连接到RDMS的“主”数据存储区，以存储诸如用户，角色，过滤器等平台实体。应用程序实体可以分散在任意数量的不同存储区中。

例如，下图表示应用程序的数据存储结构，该应用程序在数据库级别与ERP系统集成在一起，使用MongoDB作为文档存储，并使用REST API连接到远程信息系统。 CUBA的本机零件以绿色显示，自定义零件以黄色显示。

资料储存库

混合数据模型和定制数据存储为创建微服务（或更具体地说，自包含系统）开辟了道路。假设您有一个Sales应用程序，其中包含用于管理客户和产品的功能。您可以将应用程序分为三个独立的项目：Sales，Customers和Products，每个项目都有自己的数据库和UI。在“销售”应用程序中，您将创建两个其他数据存储库以与其他应用程序集成。在最简单的情况下，数据存储区可以是内置的RdbmsStore，因此Sales应用程序将仅连接到其他数据库。为了实现更宽松的耦合，您可以使用REST API创建自定义数据存储，并将远程数据映射到Sales数据模型的非持久实体。因此，您将拥有三个相对较小的独立应用程序：客户和产品可以独立工作，销售包含基于标准CUBA机制但使用远程系统数据的业务逻辑和UI。

现在，来自不同数据存储的实体不能具有直接关系。这意味着，如果您要创建来自不同商店的实体的引用，则必须为“外国”实体的ID创建一个持久属性，为该实体本身创建一个非持久属性，并处理其加载和保存以编程方式。在将来的平台版本中，我们将提供在应用程序级别上链接实体的简单声明方式。

使用Studio，您可以在“项目属性”页面的“高级”选项卡上快速配置其他数据存储（RDBMS或自定义）。

有关数据存储配置的详细信息，请参见文档。

基础实体类

我们重构了实体的基类，以使它们更加轻巧。现在，最小实体只能具有一个必需的系统属性-id，并且可以将其映射到几乎任何数据库类型，包括IDENTITY。此外，还支持复合键。

这意味着现在您可以为几乎所有现有数据库创建CUBA实体，而无需修改其架构。因此，例如，您的新CUBA应用程序可以与旧版数据库以及旧版系统同时使用。它还允许您通过将第三方系统的数据库连接为其他数据存储来与它们集成。

单点登录

CUBA应用程序的单点登录（SSO）允许用户通过在浏览器会话中输入一次登录名和密码来登录到多个正在运行的应用程序。在使用多个系统时，此功能对于无缝的用户体验至关重要。当不使用LDAP集成时，它还可以帮助管理员在一处管理用户密码。
由于任何CUBA应用程序都可以是身份提供者（IDP），它是SSO基础结构的核心元素，因此CUBA SSO只需很少的设置即可。所有配置都可以在部署阶段完成，因此在开发应用程序时不必担心。

该图显示了具有两个应用程序的SSO系统。应用程序1同时是身份提供者和服务提供者（即只是提供某些功能的应用程序）。它包含一个特殊的登录表单，显示给SSO系统的所有用户。 App 2是一个服务提供商，它将用户重定向到App 1 IDP进行登录。用户密码仅由IDP检查，但用户角色和权限是完全分开的。

请参阅文档中有关单点登录的更多信息。

匿名用法

现在，您无需登录即可创建具有UI屏幕的应用程序。该平台包含一个预定义的“匿名”用户，因此代表该用户执行登录之前运行的所有应用程序代码。默认情况下，匿名用户具有所有权限，因此在允许匿名访问之前，请不要忘记创建仅具有必需权限的角色。

工作原理：应用程序中有两个顶级窗口：登录窗口和主窗口。前者适用于匿名用户，后者适用于经过身份验证的用户。默认情况下，登录窗口仅包含登录表单，但是您可以向其中添加任何可视组件和数据源，甚至可以添加主窗口元素（例如用于打开其他屏幕的WorkArea）。为了创建您自己的匿名访问登录窗口，请转到Studio中的“屏幕”部分，然后单击“创建登录窗口”。

新的REST API

平台中已包含很长时间的通用REST API的第一个版本并不是完全RESTful的-它实际上是一个Web API，可通过HTTP提供CRUD和查询执行。在平台版本6.3中，我们引入了一个全新的REST API v2 ，该API符合REST的体系结构样式：URI和HTTP动词的使用，OAuth2身份验证。与改进的JSON序列化一起，新的REST API大大简化了Web和移动客户端应用程序的创建。

除了使用实体进行CRUD操作之外，REST API v2还允许您执行预定义的JPQL查询并调用服务方法。方法必须由开发人员明确允许，并且可以接受和返回简单类型，实体和POJO以及这些类型的集合。这种灵活的服务处理方式使您不必创建仅用于将Java类型转换为JSON的Spring MVC控制器-这种转换通常可以自动完成。因此，您只需在中间件上创建常规服务，然后在rest-services.xml中注册公开的方法。之后，您可以从客户端传递参数并以JSON接收结果来调用这些服务方法。

新的REST API还提供了用于获取当前用户详细信息和权限，有关应用程序数据模型的信息以及有关REST API本身的机器可读文档的端点。

屏幕代理

在新的平台版本中，有一种机制可让您将UI屏幕调整为适用于不同的设备：台式机，平板电脑，电话。您只需为每个受支持的设备创建多个版本的屏幕布局，并为其指定相同的ID，但使用不同的屏幕代理值。然后在运行时，平台将根据用户从中访问应用程序的当前设备选择适当的屏幕版本。

这种简单的方法并不是真正的响应方式，因为例如，当用户更改设备方向时，屏幕将不会转换。如果您不介意通过媒体查询编写CSS，请使用CssLayout容器获取完全响应的屏幕。

查询缓存

毫无疑问，使用数据库时，缓存是最有效的性能优化。现在，除了实体缓存之外，您还具有带有非常简单的API的查询缓存。这意味着您可以为ORM查询的LoadContext查询或数据源设置数据源的可缓存属性，下次您使用相同参数执行查询时，该查询的结果将被缓存并重用。当然，当您更新或删除查询中使用的类型的实体时，查询会自动从缓存中退出。

不要忘记为查询缓存中涉及的实体设置实体缓存-这两个缓存应该协同工作。