华为云用户手册

3、x-imports 作用： 自主定义类中需要添加的 import 引用。 标签值类型： List 使用位置： x-imports（当定义在swagger的最外层时，所有的类中都会引入import） components.schemas.model.properties.property.x-imports（当定义在dto的字段中时，只会在该dto类中引入import） definitions.model.x-imports（当定义在dto上时，只会在该dto类中引入import） paths.path.operation.x-imports（当定义在api中时，只会在该api中引入import） 在生成代码的时候，最终会有格式化的一个步骤，类上的无用import会被消除。 使用示例： swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-imports: - "org.springframework.stereotype.Controller;" # 使用的时候结尾一定要带上 ; - "org.springframework.transaction.annotation.Transactional;" 使用效果： 使用前：api类中不生成org.springframework.stereotype.Controller; 和org.springframework.transaction.annotation.Transactional;引用。 使用后：api类中生成如下引用。 import org.springframework.stereotype.Controller; # 通过x-import引入import org.springframework.transaction.annotation.Transactional; # 通过x-import引入public interface CARDApi { -------);

18、x-interface-name-style 作用： 控制自定义接口、实现类命名风格。 标签值类型： enum（DEFAULT，SERVICE_IMPL_AND_NO_I_INTERFACE_PREFIX），配置为DEFAULT时和不配置此参数效果相同。 使用位置： x-interface-name-style 使用示例： swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-entity-package: "customdto"x-interface-name-style: SERVICE_IMPL_AND_NO_I_INTERFACE_PREFIX ------------ 使用效果： 使用前： service类的命名为 I+tag驼峰+ serviceeg： IOrderService 使用后： service类的命名为 tag驼峰+ serviceeg： OrderService

9、x-type 作用： 给dto的字段设置指定的类型。 标签值类型： String 使用位置： components.schemas.model.prorperties.field.x-type（设置在dto的指定字段上时，改变该字段的类型为指定类型） 使用示例： definitions： Contain: type: "object" x-generic: T x-extends: Parent properties: name: type: "string" description: "" example: data: type: "string" x-type: T # 通过x-type指定data的类型为T， 此处是将T当为一个字符串设置上，如果设置为一个对象时，需要使用x-imports手动导入相应的包 xml: name: "Contain" namespace: "com.huaweicloud.icsl.app.dto" --------------- 使用效果： 使用前： public class Contain implements Serializable { private static final long serialVersionUID = 1L; @JsonProperty("name") private String name = null; @JsonProperty("data") private String data = null;} 使用后： public class Contain implements Serializable { private static final long serialVersionUID = 1L; @JsonProperty("name") private String name = null; @JsonProperty("data") private T data = null;}

16、x-enum-class-name 作用 用于标识查询参数对应的枚举类。 标签值类型 String 使用位置 paths.path.operation.parameters.fields.x-enum-value-type 对应的是swagger中已定义的枚举对象名字。 使用示例 Paths: /v1/orders/{order_id}/order-details: get: tags: - "Order" summary: "查询OrderDetail" description: "Returns OrderDetail" operationId: "ListOrderDetails" x-is-registered: 'N' x-support-sdk: 'N' x-mybatis-paging: true consumes: - "application/json" produces: - "application/json" parameters: - name: "status" in: "query" description: "status" required: false type: "string" x-enum-class-name: "OrderStatus" #此标签只在查询参数中使用 -------- 使用效果： 使用前： public class ListOrderDetailsQo implements Serializable { private static final long serialVersionUID = 1L; @JsonProperty("status") private Object status = null; -------------------} 使用后： public class ListOrderDetailsQo implements Serializable { private static final long serialVersionUID = 1L; @JsonProperty("status") private OrderStatus status = null; -------------------}

17、x-entity-package 作用： 用于在swagger中指定实体类dto生成的包名。 标签值类型： String 使用位置： x-entity-package（定义在swagger的最外层） 使用示例： swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-entity-package: "customdto" ------------ 使用效果： 使用前： #dto对象生成目录 xxx.xx.xx.dto 使用后： #dto对象生成目录 xxx.xx.xx.customdto

5、x-class-annotations 作用： 添加指定的注解。 该标签用于在api接口或者dto类上添加指定的注解。 标签值类型： List 使用位置： x-class-annotations（定义在swagger的最外层时，会在所有的api接口上都添加指定的注解） components.schemas.model.x-class-annotations（定义dto对象上时，只在该对象上添加指定的注解） 使用示例： swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-imports: - "org.springframework.stereotype.Controller;" # 使用的时候结尾一定要带上 ; - "org.springframework.transaction.annotation.Transactional;"x-class-annotations: #此处添加的注解，在所有生成的api上都会添加 - "@Controller" # 此处会将 @Controller识别为一个字符串添加到api接口类上，并不会导入相应的包，需要使用 x-imports标签手动导入相应的包 - "@Transactional" # 此处会将 @Transactional识别为一个字符串添加到api接口类上，并不会导入相应的包，需要使用 x-imports标签手动导入相应的包 使用效果： 使用前： package com.huaweicloud.icsl.api;import ------/** * CARDApi interface */public interface CARDApi { -----------} 使用后： package com.huaweicloud.icsl.api;import org.springframework.stereotype.Controller; // 通过x-imports 引入的导包import org.springframework.transaction.annotation.Transactional; // 通过x-imports 引入的导包/** * CARDApi interface */@Controller // 通过x-class-annotations 引入的注解@Transactional // 通过x-class-annotations 引入的注解public interface CARDApi { -----------}

4、x-annotations 作用： 添加指定的注解。 该标签用于在api的参数或者dto指定属性上添加注解。 标签值类型： List 使用位置： paths.path.operation.parameters.x-annotations（定义在api中的参数上时，只在此参数上生成对应的注解） definitions.model.properties.property.x-annotations（定义在dto的字段上时，只在此字段上生成对应的注解） 使用示例： Card: type: "object" properties: id: type: "string" description: "id" example: "id" balance: type: "integer" format: "int64" description: "balance" example: 123 address: type: "string" description: "address" example: "address" x-annotations: - "@InjectMocks" # 此处在address属性上添加了一个 @InjectMocks 注解 x-imports: - "org.mockito.InjectMocks;" # x-annotations实际是把 @InjectMocks当做字符串添加到了address上，所以需要自己通过x-imports导入相应的类 creator: type: "string" description: "creator" example: "creator" create_time: type: "string" format: "date-time" default: "CURRENT_TIMESTAMP" description: "create time" example: "2020-02-27 15:00:08" modify_time: type: "string" format: "date-time" default: "CURRENT_TIMESTAMP" description: "modified time" example: "2020-02-27 15:00:08" description: type: "string" description: "description info" example: "description" xml: name: "card" namespace: "com.huaweicloud.icsl.model" 使用效果： 使用前： public class Card implements Serializable { private static final long serialVersionUID = 1L; ----- @JsonProperty("address") private String address = null; ----} 使用后： public class Card implements Serializable { private static final long serialVersionUID = 1L; ------- @JsonProperty("address") @InjectMocks // 通过 x-annotations 引入的注解 private String address = null; --------}

21、x-pom-gav 作用 自定义标签-pom坐标引入。 标签值类型 List 使用位置 x-pom-gav components.schemas.model.x-pom-gav components.schemas.model.properties.property.x-pom-gav paths.path.operation.x-pom-gav paths.path.operation.parameters.name.x-pom-gav x-pom-gav在Swagger文件中的位置可以是类级别、方法级别、参数级别，groupId、artifactId、version按照顺序用：连接，全局有一个地方定义即可，不需要重复定义。 使用示例 swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-entity-package: "customdto"x-interface-name-style: SERVICE_IMPL_AND_NO_I_INTERFACE_PREFIXx-user-defined-consumes: truex-pom-gav: # 手动引入hibernate-validator:依赖 - "org.hibernate.validator:hibernate-validator:8.0.1.Final"------- 使用效果： 使用前： pom中没有org.hibernate.validator:hibernate-validator:8.0.1.Final的依赖 使用后： pom中生成org.hibernate.validator:hibernate-validator:8.0.1.Final的依赖

6、x-controller-annotations 作用： 添加指定的注解。 该标签用于在api实现类上添加指定的注解。 标签值类型： String 使用位置： x-class-annotations（定义在swagger最外层，所有的api实现类上都会添加指定注解） components.schemas.model.x-class-annotations（定义在指定tag下，只会在具体api实现类上添加指定注解） 使用示例： swagger: "2.0"info: description: "" version: "v1" title: "testSwagger" termsOfService: "http://www.coarl.org/service.html"host: "git.huawei.com"basePath: "/testswagger"x-imports: - "org.springframework.context.annotation.Profile;" # 使用的时候结尾一定要带上 ;x-controller-annotations: # 此处添加的注解，在所有生成的api实现类上都会添加，需要使用x-imports手动导入相应的包 - '@Profile("test")' 使用效果： 使用前： public class CardApiController implements CardApi { ------} 使用后： @Profile("test") // 通过x-controller-annotations引入的注解public class CardApiController implements CardApi { ------}

base代码目录结构 代码结构说明中的“{biz}”，为在AstroPro的业务设计中定义的对象，如BO、Abstract BO等。 com.astropro|-- controller # API层代码，定义向外部服务暴露的接口（必填项） {biz}Api.java {biz}Controller.java|-- service # 承接API直接调用，基本的业务判断逻辑和分发。service层目录，包含接口层（必填项） I{biz}Service.java # service接口层代码|-- repository # 数据操作聚合层（必填项） Abstract{biz}Repository.java # 数据操作聚合层代码。|-- mapper # 数据原子操作层。mapper层目录，包含基本接口（必填项） {biz}Mapper.java # mapper层接口代码|-- model # 业务对象层，包含实体类、枚举类、查询对象和mybatis查询条件对象 {biz}.java # 实体类（可选项） {xxx}Enum.java # 枚举类（可选项） {biz}Qo.java # 查询对象（可选项） {biz}Criteria.java # mybatis查询条件对象（可选项）|-- dto # 数据传输对象，do组合对象（可选项） |-- nested # 根据业务对象的关系自动关联生成，嵌套复杂对象（可选项） |-- cartesian # 根据业务对象的关系自动关联生成，正交的笛卡尔积对象（可选项） |-- {customDto}.java # 用户预先定义好的数据传输对象（可选项）|-- utils # 工具类（必填项）|-- resources # 资源目录结构 |-- mapper # 开源组件mybatis的mapper.xml文件存放目录 {biz}Mapper.xml # 该目录下的文件禁止用户改动

base资源目录结构 代码结构说明中的“{biz}”，为在AstroPro的业务设计中定义的对象，如BO、Abstract BO等。 resources # 资源目录结构|-- mapper # 开源组件mybatis的mapper.xml文件存放目录 {biz}Mapper.xml # 该目录下的文件禁止用户改动

service层资源目录结构 代码结构说明中的“{biz}”，为在AstroPro的业务设计中定义的对象，如BO、Abstract BO等。 resources # 资源目录结构|-- mapper # 开源组件mybatis的mapper.xml文件存放目录 {biz}CustomMapper.xml # 用户可在此文件中实现自定义的方法|-- openapi # swagger.yaml存放目录 swagger.yaml # swagger.yaml文件 application.yml # SpringBoot全局配置文件 banner.txt # 应用程序的banner文件 log4j2.xml # log4j2日志配置文件 metadata.json # 元数据配置文件

service层代码结构 代码结构说明中的“{biz}”，为在AstroPro的业务设计中定义的对象，如BO、Abstract BO等。 com.astropro|-- service # 承接API直接调用，基本的业务判断逻辑和分发。service层目录，只包含实现层，用户可自定义实现service层逻辑（必填项） {biz}Service.java # service实现代码（必填项）|-- repository # 数据操作聚合层（必填项） {biz}Repository.java # 数据操作聚合层继承类代码。用户可在此类中覆写基类中的方法或者增加自定义的方法|-- mapper # 数据原子操作层，mapper层目录（必填项） {biz}CustomMapper.java # mapper层用户自定义mapper接口代码，用户可在此类中用户可在此类中实现自定义mapper接口|-- enums # 枚举类（必填项）|-- config # 配置类（必填项）|-- utils # 工具类（必填项）|-- exception # 异常类（必填项）|-- integration # 集成第三方服务，隔离外部系统的影响，起防腐作用（可选项）|-- event # 事件层（可选项） |-- publish # 发布事件的Package，存放事件发布的工具类与发布的事件对象，屏蔽技术组件对应用业务的侵入 |-- subscribe # 订阅事件的Package，存放listener与消费的事件对象，listener只做数据的监听与数据格式的转换

步骤5：服务依赖 通常情况下，一个应用不是一个单独的服务，可能由多个服务共同组成。这些服务之间可能存在一些跨服务的调用，此时就需要通过添加依赖服务，把这些服务的客户端集成过来。添加依赖服务前，请确保依赖服务的“是否生成客户端”按钮已启用。 图1 开启“是否生成客户端”配置 在服务依赖中，选择当前服务依赖的服务。 图2 选择依赖的服务 选择依赖服务的版本号。 在依赖强弱中，选择strong（强）或weak（弱），单击“添加”，完成依赖服务的添加。 图3 完成依赖服务的添加 选择客户端的依赖类型，支持“SDK”和“METHOD”两种类型，可按需选择。 （可选）添加客户端流控策略。 选择SDK类型时，无须配置流控策略。 选择“METHOD”类型后，单击“编辑”，可为对象方法配置流控策略。例如：为User对象的addOder添加一个Retry的流控策略，如图4所示。 您可以选择系统预置的流控策略，也可以选择自定义流控策略。选择自定义流控策略需提前在资产库中创建客户端流控策略。 单击“保存”，完成流控策略配置。 图4 为对象添加方法的流控策略 父主题： 编辑服务

了解服务创建流程 在AstroPro中创建一个服务的流程，如图1所示。 图1 创建服务流程图 新增一个服务 创建一个空服务，并指定服务的版本。创建服务前，请确保已创建项目和服务组。 基本配置 设置服务框架、版本和单元化策略等信息，请根据实际业务直接在界面进行勾选。 框架配置 设置服务的架构、数据库、缓存和安全认证等信息，请根据实际业务直接在界面进行勾选。 生成策略 设置服务的API、代码风格、部署和性能测试等信息，请根据实际业务直接在界面进行勾选。 业务设计 基本配置、框架配置和生成策略需要用户根据自身业务的实际情况进行配置，配置不同生成的效果有所不同。业务设计是AstroPro的核心能力，是用户设计自己业务的基础。 服务依赖 通常情况下，一个应用不是一个单独的服务，可能由多个服务共同组成。这些服务之间可能存在一些跨服务的调用，此时就需要通过添加依赖服务，把这些服务的客户端集成过来。 生成服务代码 根据配置的业务模型，生成服务的代码。

添加自定义API 在业务设计页面，选中某个业务对象。 单击右侧属性配置中的“自定义API”，进入编辑自定义API页面。 单击“新增”，按需添加所需的API。 实例级别：定义API实例的级别，如类型、实例。 动作名称：设置API的动作名称。 请求方法：HTTP请求方法（也称为操作或动作），用于告诉服务您正在请求什么类型的操作。 get：请求服务器返回指定资源。 put：请求服务器更新指定资源。 post：请求服务器新增资源或执行特殊操作。 delete：请求服务器删除指定资源。 请求对象：单击“添加请求对象”，可添加请求对象，即API请求的输入参数。 返回对象：请求发送后，您会收到的响应，如状态码。 路径：单击“输入path”，添加API的路径，格式为变量放到“{}”中，单词用“_”连接，非变量单词用“-”连接。例如：/meta-bo1s/{meta_bo1_id}/test-action。 当您没有自定义API路径，且“实例级别”选择“实例”时，生成的API路径上会拼接一个{MetaBo}_id的路径，同时方法上会多生成一个当前MetaBo主键的参数，如图2所示。 图2 API路径 描述：输入自定义API的描述信息。 设置代码生成层，参数设置与代码生成关系请参考表1。 表1 设置代码生成层组合说明 接口层 应用层 数据访问层 代码生成 x √ x 仅在应用层生成代码。 x x √ 仅在数据访问层生成代码。 √ √ x 在接口层和应用层生成代码。 x √ √ 在应用层和数据访问层生成代码。 √ √ √ 在接口层、应用层和数据访问层皆生成代码。 图3 设置代码生成层 设置完成后，单击“保存”。

示例 创建服务时“Package”设置为“com.astropro”。在业务设计中添加自定义API，动作名称为action1，请求方式为GET，返回对象为200，代码生成层勾选接口层和应用层，则代码生成时，将在接口层和应用层生成对应API的代码，如图6所示。 图4 设置打包路径 图5 添加自定义API 图6 查看生成代码 表2 不同目录结构下实际影响代码路径说明 目录结构 接口层 应用层 数据访问层 DDD {package}.api.xxx {package}.app.xxx {package}.infrastructure.repository.base.xxx Single {package}.api.xxx {package}.service.xxx {package}.repository.base.xxx base/service {package}.api.xxx {package}.service.xxx {package}.repository.base.xxx package为创建服务时定义的打包路径。

3、了解AstroPro中的项目、服务组与服务之间的关系 项目是使用AstroPro核心业务的入口。服务组用于对项目中的服务进行分组，一般一个分组对应一个研发团队。服务组创建后，即可为项目添加服务。服务是业务概念，即提供某种服务的某个进程。每一个服务都具有自主运行的业务功能，对外开放不受语言限制的API，多个服务组成应用程序。 在AstroPro中，项目、服务组和服务之间的关系，如图1所示。 图1 项目、服务组与服务的关系

4、熟悉如何进行业务设计 在AstroPro中，用户通过业务设计，可生成高可用、高可靠、以及安全稳定的企业级IT应用框架。 对象：对象可以理解为数据库中创建的一个表。每个对象对应一张数据库表，用于保存业务系统需要的配置数据和业务数据。对象可以存储组织或业务特有的数据，您可以围绕对象这一核心，定义相关的字段、字段校验规则、界面样式、字段变更时的触发事件等。如果把待开发的业务系统比作一部电影，对象就是电影中的各个角色，需要勾勒角色的外貌、性格特点、人物关系和所经历的剧情。 AstroPro提供了BO、Abstract BO和Value Object三种类型的对象，请根据业务需求进行选择。 BO：业务对象，业务对象映射到服务中的一个实体，对应数据库中的一张表。 Abstract BO：抽象对象，不能实例化，没有对应的数据库表，需要和业务对象有个继承的操作。例如，业务对象A继承一个抽象对象B，则B中的字段都会被A继承过来。 Value Object：值对象，不能单独存在，需要和业务对象建立聚合的关系。 对象间关系：关系描述了不同元素之间的关联和联系，在AstroPro中您可以定义一对多、多对多、聚合和继承等关系。

自定义DTO 在业务设计页面，单击“自定义DTO”。 图1 自定义DTO 单击“新增”，添加一个自定义DTO。 图2 自定义一个Dto1 在自定义API的参数或返回体中，使用自定义DTO。 从“business”中，拖拽“BO”对象至画布空白区域。 选中BO对象，在对象属性中，单击“自定义API”。 图3 自定义API 单击“新增”，添加一个自定义API。 图4 自定义一个API 在请求对象或返回对象的参数中，使用自定义DTO。 图5 在自定义API中使用自定义DTO

了解构建流程 在AstroPro中，用户通过业务建模，可生成高可用、高可靠、以及安全稳定的企业级IT应用框架。业务建模是指通过业务设计，将实际业务涉及的对象和行为转换为元数据中的对象、对象关系、服务依赖等构成的模型，通过模型生成服务，实现业务需求。 使用AstroPro创建企业核心应用的流程，如图1所示。 图1 创建企业核心应用流程图 创建项目 项目是使用AstroPro核心业务的入口。在使用AstroPro前，需要先创建一个项目。 创建服务组 服务组用于对项目中的服务进行分组，一般一个分组对应一个研发团队。创建项目后，默认会创建一个和项目同名的服务组，所有新建服务默认在此分组下。 添加服务 在新增服务界面，通过简单的配置，完成服务框架的搭建。 编辑服务 添加服务的操作，相当于为服务搭建了一个框架。如果需要服务实现某些特定的功能，还需要您根据业务需求，对服务进行业务模型配置。 生成服务代码 基于配置的业务模型，生成服务的基本代码。代码生成后，会提供一个压缩包，供您直接使用。 父主题： 创建企业核心应用

属性说明 在业务设计页面，从“business”中，拖拽“Abstract BO”对象至画布空白区域。选中对象，在右侧页面设置对象属性，如图4所示。 图4 Abstract BO 对象名称：设置对象的名称，必须使用大驼峰格式，不允许存在连续的大写字母。 中文名：设置对象的中文名称。 软删除策略：开启软删除策略后，数据删除时执行逻辑删除，数据仍然保留在数据库中。关闭软删除策略后，数据删除为物理删除，即直接从数据库中删除，不可恢复。 注意：购买AstroPro企业版实例时，才会显示“软删除策略”配置项。 恢复软删除：当开启“软删除策略”时可配置。开启恢复软删除，则支持将软删除的数据恢复。 操作：对新建的对象可执行哪些操作，如新增、更新、删除、查询、批量新增、批量更新、批量查询、批量删除和自定义查询。默认值为新增、更新、删除、查询和批量查询。 对象版本化：通过版本号的机制实现的乐观锁功能。开启此功能时，会在表中自动添加一个devspore_verion的字段来记录版本。在更新操作时会检查当前版本号和DB中的版本号是否一致，一致则更新数据并增加版本号，如果不同则说明数据已被其他事务修改，更新失败。 注意：购买AstroPro企业版实例时，才会显示“对象版本化”配置项。 对象描述：对象的描述信息。 字段：单击右侧属性配置的“字段”，可以为对象添加所需的字段。

功能介绍 Abstract BO是一个抽象对象，不能单独存在，没有数据库表，需要和业务对象建立继承的关系。建立继承关系后，业务对象会继承抽象对象中的字段。例如，抽象对象Abstract和业务对象Role存在继承关系，在抽象对象Abstract中，新建一个name字段，该字段会被Role自动继承。 图1 和业务对象Role建立继承关系 图2 在Abstract BO中新建一个name字段 图3 Role中继承name字段

关系属性设置 在业务设计页面，拖入两个BO业务对象（命名为Primary、Secondary），单击“relations”中的“一对多”，为对象建立一对多关系。选中已创建的关系，在右侧页面即可设置关系属性，如图2所示。 图2 一对多关系 关系名称：设置一对多关系的名称。 关系类型：根据创建的一对多关系自动生成。 关系首要方：根据创建的一对多关系自动生成。 关系次要方：根据创建的一对多关系自动生成。 DTO暴露方式 - NESTED：是否设置DTO的NESTED（嵌套）能力。默认为不设置。 不设置：不生成NESTED。 只生成DTO：只生成NESTED对象的类。 生成DTO读API：只会生成一个get接口。 生成DTO读写API：除了生成一个get接口，还会生成一个插入接口。 DTO暴露方式 - CARTESIAN：设置DTO的CARTESIAN（笛卡尔积）能力。 不设置：不生成CARTESIAN。 只生成DTO：只生成CARTESIAN对象的类。 生成DTO读API：只会生成一个get接口。 每个Primary关联最大Secondary数：一个首要方和次要方建立关联的数量上限。 每个Secondary最大关联Primary数：一个次要方和首要方建立关联的数量上限。 每个Primary关联最大Secondary维度上限预警值：首要方一条数据最多关联次要方多少条数据报出告警。

步骤4：业务设计 步骤1：基本配置、步骤2：框架配置和步骤3：生成策略中参数，只需要用户根据自身业务直接在界面进行勾选配置。而业务设计需要用户根据实际的需求，进行业务模型的设计和配置。 例如，创建一个简单的订单系统，订单系统中包括用户（User）、订单（Order）和订单详情（OrderDetail）三个业务对象，且三个对象之间存在聚合关系，即用户存在时，订单才会存在，订单存在时，订单详情才会存在。同时一个用户可以关联多个订单，订单通过单号进行标识，一个订单又可以关联多个商品，例如手机、耳机等，商品可以记录数量。实现上述业务逻辑，需要进行如下设计： 在业务设计页面，拖拽所需的对象到设计区，并修改对象名称。 AstroPro提供了BO、Abstract BO和Value Object三种类型的对象，请根据业务需求进行选择。 BO：业务对象，业务对象映射到服务中的一个实体，对应数据库中的一张表。 Abstract BO：抽象对象，不能实例化，没有对应的数据库表，需要和业务对象有个继承的操作。例如，业务对象A继承一个抽象对象B，则B中的字段都会被A继承过来。 Value Object：值对象，不能单独存在，需要和业务对象建立聚合的关系。 本示例中，拖拽三个BO对象到设计区，选中对应的BO，修改对象名称为User、Order和OrderDetail。 图1 拖拽三个BO到设计区 设置对象属性。 本示例中，因为一个用户需要关联多个订单，订单通过单号进行标识，一个订单又可以关联多个商品，商品可以记录数量。所以需要为“User”添加“name（用户名）”字段，用于记录用户信息。为“Order”添加“orderNo（订单编号）”字段，用于记录订单的编号。为“OrderDetail”添加“product（商品）”、“amount（数量，integer类型）”字段，分别用于记录商品的详情和商品的数量。 图2 为User对象添加name 图3 为Order添加orderNo 图4 OrderDetail添加product和amount 建立对象之间的关系。 AstroPro提供了一对多、多对多、聚合、树递归和继承五大关系，请根据自身业务需求进行选择。各对象间关系详细介绍，请参见对象间关系。 本示例中的订单系统，当用户存在时，订单才会存在，订单存在时，订单详情才会存在，此时需要为三个对象之间建立聚合关系。聚合关系中，次要方必须依赖首要方，任何对于次要方的操作首先要经过首要方才能继续往下操作。在User和Order的聚合关系中，User为首要方，Order为次要方，即用户存在时，订单才会存在。在Order和OrderDetail的聚合关系中，Order为首要方，OrderDetail为次要方，即订单存在时，订单详情才会存在。 图5 设置对象间关系 设置完成后，单击“下一步”，进行服务依赖设置。 父主题： 编辑服务

步骤1：基本配置 基本信息中配置的内容会呈现在代码中，需用户根据实际情况进行勾选配置。 在服务列表中，单击新增一个服务中已创建服务后的“编辑”。 在基本配置中，按需进行设置。 图1 基本配置 基本配置：若本地已有配置好的服务元数据，可通过单击“导入元数据”，直接导入。 微服务名称：自动关联新增一个服务中创建的服务名称。 Group ID：服务所属项目中的组ID，会自动关联新建项目中Group的值。在Maven项目中用作工程组的标识，Group ID在一个组织或项目中通常是唯一的。 Package：设置生成代码的顶层包名，会自动关联新建项目中Package的值。 Artifact ID：在Maven项目中用作工程的标识，通常是工程的名称。 版本：在Maven项目中用作工程的版本号。 框架：选择微服务使用的开发框架，支持DEVSPORE(JDK 8 + SpringBoot 2)和DEVSPORE(JDK 17 + SpringBoot 3)。 DEVSPORE(JDK 8 + SpringBoot 2)：生成JDK8+SpringBoot2的代码框架。 DEVSPORE(JDK 17 + SpringBoot 3)：生成JDK17+SpringBoot3的代码框架。 在详细配置中，配置服务的详细信息。 图2 详细配置 服务类型：当前仅支持创建原子服务。原子服务是指对外提供业务对象管理API，有独立数据存储（一般为独立数据库）的服务。原子服务之间可以相互调用。 服务组：选择服务所属的分组。如何创建服务组，请参见新建服务组。 服务单元化策略：服务在子域内的单元化策略。服务单元化策略必须在一个子域内定义，不能跨子域。 SINGLE：即单库，无论子域是否进行单元化部署，该服务只在一个单元（一般以region为单元）内部署。 ROOTED：根服务，包含根业务对象的服务，每个子域最多有一个根服务。 SHARDING：分片服务，必须按照根服务的根业务对象的维度对数据进行分片，和根服务使用同样的数据单元化策略。只有子域中包含根服务的时候，才允许有分片服务；一个子域可以包含的分片服务数量为0..n。分片服务有两种方式和根服务建立关系：可以通过建立根维度映射表，其它sharding表外键引用它的方式。也可以直接为每个表加一个根维度表id字段。 API版本：服务的API版本，默认为新增一个服务时配置的版本，如果需要升级API的版本，请参见升级API版本。 是否启用扩展拦截：通过引入devspore-horizon插件，用户自定义继承抽象类Approve和添加配置，在请求进入和返回时增强处理。您可调用DevSpore预置的插件，也可以使用自己开发的插件，自定义插件可参考devspore-horizon介绍。 启用扩展拦截时，自动在pom文件中引入devspore-horizon插件，并在所有service实现类的方法上添加“@Extension”注解。同时在plugin目录下，生成“DefaultRequestPlugin.java”示例文件。 使用插件时，用户需要在配置文件中添加devspore.horizon.processors，即配置自己编写的扩展插件注入到spirng中的名称，多个插件之间使用英文逗号隔开，扩展插件需要继承com.huawei.devspore.horizon.approver.Approve抽象类，并重写其中的doApprove方法。 注意：启用扩展拦截仅专业版及以上套餐支持，如果您需要使用此功能，请升级Astro Pro实例版本。 客户端配置。 客户端配置仅专业版及以上套餐支持，如果您需要使用此功能，请升级Astro Pro实例版本。 是否生成客户端：是否生成客户端的代码。开启后，会生成服务的客户端代码，如图3。 图3 生成客户端的代码 客户端类型：目前仅支持“OPEN_FEIGN” 设置完成后，单击“下一步”，进入框架配置页面。 父主题： 编辑服务

关系属性设置 在业务设计页面，拖入一个BO业务对象和一个Abstract BO对象（命名为Role、Abstract），单击“relations”中的“继承”，为对象建立继承关系。选中已创建的关系，在右侧页面即可设置关系属性，如图3所示。 图3 继承关系 关系名称：设置继承关系的名称。 关系类型：根据创建的继承关系自动生成。 关系首要方：根据创建的继承关系自动生成。 关系次要方：根据创建的继承关系自动生成。

步骤三：新建一个页面 单击“页面管理”的新增页面按钮。 设置页面基本属性。 选择页面类型：可选“静态页面”或“公共页面”。 页面名称：只允许包含英文字母，且以大写开头驼峰格式，如DemoPage。 选择文件夹：下拉框中选择文件夹名称。 路由：输入路由信息，只允许包含英文字母、数字、下划线、中划线和正斜杠组成， 且以英文字母开头。 图4 创建页面 单击“保存”。 在弹框中输入历史备份信息，单击“确定”。

关系属性设置 在业务设计页面，拖入两个BO业务对象（命名为Bo3、Bo4），单击“relations”中的“多对多”，为对象建立多对多关系。选中已创建的关系，在右侧页面即可设置关系属性，如图2所示。 图2 多对多关系 关系名称：设置多对多关系的名称。 关系类型：根据创建的多对多关系自动生成。 关系首要方：根据创建的多对多关系自动生成。 关系次要方：根据创建的多对多关系自动生成。 表名：设置关系表的名称，请按需自定义。在多对多关系中，会建立关系表用来保存首要方和次要方id的关系。 DTO暴露方式 - NESTED：是否设置DTO的NESTED（嵌套）能力。默认为不设置。 不设置：不生成NESTED。 只生成DTO：只生成NESTED对象的类。 生成DTO读API：只会生成一个get接口。 生成DTO读写API：除了生成一个get接口，还会生成一个插入接口。 DTO暴露方式 - CARTESIAN：设置DTO的CARTESIAN（笛卡尔积）能力。 不设置：不生成CARTESIAN。 只生成DTO：只生成CARTESIAN对象的类。 生成DTO读API：只会生成一个get接口。 关系操作：对象关系可执行哪些操作，如新增、删除、查询、批量新增、批量删除和批量查询。 每个Bo3关联最大Bo4数：一个首要方和次要方建立关联的数量上限。 每个Bo4关联最大Bo3数：一个次要方和首要方建立关联的数量上限。 每个Bo3关联最大Bo4维度上限预警值：首要方一条数据最多关联次要方多少条数据报出告警。 每个Bo4最大关联Bo3维度上限预警值：次要方一条数据最多关联首要方多少条数据报出告警 字段：多对多的关系是通过一个关系表来表示的。单击“字段”，可为关系表添加字段。

关系标签 一对多关系 在MANY一方的关系字段上添加标注：COMMENT 'relation("关联表名","关联表字段","ONE2MANY")'。 DDL示例： CREATE TABLE `t_workspace2` ( `id` varchar(200) NOT NULL, `new_name3` varchar(200) NOT NULL, `new_name4` varchar(200) NOT NULL, PRIMARY KEY (`id`)) COMMENT = 'primaryKeyType("UUID")';CREATE TABLE `t_workspace3` ( `id` varchar(200) NOT NULL, `new_name4` varchar(200) NOT NULL, `workspace2_id` varchar(200) NOT NULL COMMENT 'searchable;relation("t_workspace2","id","ONE2MANY")', PRIMARY KEY (`id`)) COMMENT = 'primaryKeyType("UUID")'; 标签使用效果： 多对多关系 在多对多关系表的关系字段上添加标注：COMMENT = 'relation("关联表名","关联表字段","MANY2MANY")'。 此处关系的首要方关联字段写在关系的次要方关联字段前面，即workspace4_id字段在workspace5_id前面。示例中首要方：t_workspace4，次要方：t_workspace5。 DDL示例： CREATE TABLE `t_workspace4` ( `id` varchar(200) NOT NULL, `new_name3` varchar(200) NOT NULL, `new_name4` varchar(200) NOT NULL, PRIMARY KEY (`id`)) COMMENT = 'primaryKeyType("UUID")';CREATE TABLE `t_workspace5` ( `id` varchar(200) NOT NULL, `new_name3` varchar(200) NOT NULL, `new_name4` varchar(200) NOT NULL, `new_name5` varchar(200) NOT NULL, PRIMARY KEY (`id`)) COMMENT = 'primaryKeyType("UUID")';CREATE TABLE `t_rel_workspace4_workspace5` ( `new_name3` varchar(200) NOT NULL, `new_name4` varchar(200) NOT NULL, `workspace4_id` varchar(200) NOT NULL COMMENT 'relation("t_workspace4","id","MANY2MANY")', `workspace5_id` varchar(200) NOT NULL COMMENT 'relation("t_workspace5","id","MANY2MANY")', CONSTRAINT pk_t_rel_workspace4_workspace5 PRIMARY KEY (`workspace4_id`, `workspace5_id`)) COMMENT = 'relWorkspace4Workspace5'; 标签使用效果： 聚合关系 在聚合关系的主表的关系字段上添加标注：COMMENT 'relation("关联表名","关联表字段","AGGREGATE")'。 DDL示例： CREATE TABLE `t_spec_group` ( `id` varchar(40) NOT NULL COMMENT 'id', `city_id` varchar(40) NOT NULL COMMENT 'relation("t_city","id","AGGREGATE")', `name` varchar(200) NULL, PRIMARY KEY (`id`)) COMMENT = 'specGroup';CREATE TABLE `t_city` ( `id` varchar(40) NOT NULL COMMENT 'id', `city` varchar(200) NULL, `dateType` date NOT NULL COMMENT 'dateType', PRIMARY KEY (`id`)) COMMENT = 'city'; 标签使用效果： 树递归关系 在树递归关系BO表中的"parent_id"上添加标注：COMMENT 'relation("关联表名","关联表字段","RECURSIVE")'。 DDL示例： CREATE TABLE `t_workspace6` ( `parent_id` bigint(40) NULL COMMENT 'parent_id;relation("t_workspace6","id","RECURSIVE")', `id` bigint(40) NOT NULL, `new_name4` varchar(200) NOT NULL, `new_name5` varchar(200) NOT NULL, PRIMARY KEY (`id`)) COMMENT = 'primaryKeyType("SNOWFLAKE")'; 标签使用效果：