shao

1、方式一，配置数式仓库代理 创建一个proxy类型的仓库 点击"Repository"–>“Repositories”–>“Create repository”，选择maven2(proxy)。 Name：要代理的数式的maven，自定义maven-proxy-shushi-release Online：勾选，设置成在线 ProxyRemote storage：设置远程数式仓库的地址。这里设置成数式的maven仓库地址：http://nexus.shushi.pro/repository/pamirs-releases/ 认证方式：Authentication，填写数式提供的用户名和密码； 其他的保持默认即可 用同样的方式，把数式snapshots（http://nexus.shushi.pro/repository/pamirs-snapshots/） 2、方式二，Settings融合 在Maven的配置文件中(settings.xml)，增加数式的仓库配置： <!– oinone –> <server> <id>oinone-develop-release</id> <username>数式提供的账号</username> <password>数式提供的密码</password> </server> <server> <id>oinone-develop-snapshot</id> <username>数式提供的账号</username> <password>数式提供的密码</password> </server> <!– oinone –> <repository> <id>oinone-develop-release</id> <name>Repository for pamirs releases</name> <url>http://nexus.shushi.pro/repository/pamirs-releases/</url> <releases> <enabled>true</enabled> <!– <updatePolicy>always</updatePolicy> –> </releases> <snapshots> <enabled>false</enabled> </snapshots> <layout>default</layout> </repository> <repository> <id>oinone-develop-snapshot</id> <name>Repository for pamirs snapshots</name> <url>http://nexus.shushi.pro/repository/pamirs-snapshots/</url> <snapshots> <enabled>true</enabled> </snapshots> <layout>default</layout> </repository>

1、图表设计器 数据可视化能加载到的接口，方法上需要加 category = FunctionCategoryEnum.QUERY_PAGE @Model.model(ExpensesIncome.MODEL_MODEL) @Component @Slf4j public class ExpensesIncomeAction { @Function.Advanced(type = FunctionTypeEnum.QUERY,category = FunctionCategoryEnum.QUERY_PAGE) @Function.fun(FunctionConstants.queryPage) @Function(openLevel = {FunctionOpenEnum.API}) public Pagination<ExpensesIncome> queryPage(Pagination<ExpensesIncome> page, IWrapper<ExpensesIncome> queryWrapper) { page = new ExpensesIncome().queryPage(page, queryWrapper); if (page!=null && CollectionUtils.isNotEmpty(page.getContent())) { page.getContent().forEach(a->{ if (a.getBudgetInCome()!=null && a.getBudgetInCome().compareTo(new BigDecimal("0.0"))!=0) { if (a.getRetailAmount()!=null) { a.setInComeRate(a.getRetailAmount().divide(a.getBudgetInCome(),2)); } } }); } return page; } } 2、事务支持 1）对于单个系统(InJvm)/模型内部采用强事务的方式。比如：在库存转移时，库存日志和库存数量的变化在一个事务中，保证两个表的数据同时成功或者失败。2）强事务管理采用编码式，Oinone事务管理兼容Spring的事务管理方式；有注解的方式和代码块的方式。a) 使用注解的方式： @Override @Transactional public void awardOut(AwardBookOutEmpRecordDetail detail) { List<OutEmpRecordSubjectDetail> subjectDetails = detail.getSubjectDetails(); …… } 重要说明基于注解的事务，Bean和加注解的方法必须能被Spring切面到。 b) 使用编码方式： //组装数据/获取数据/校验 Tx.build(new TxConfig()).executeWithoutResult(status -> { // 1、保存部门数据 deliDepartmentService.createOrUpdateBatch(departments); //2、如果父进行了下级关联设置，处理下级关联设置的逻辑 for (DeliDepartment department : departments) { doDepartSubLink(department); } }); ………… 3）对于分布式事务采用最终数据一致性，借助【可靠消息】或者【Job】的方式来实现。 3、平台工具类使用 3.1 FetchUtil pro.shushi.pamirs.core.common.FetchUtil，重点关注 # 根据Id查询列表 pro.shushi.pamirs.core.common.FetchUtil#fetchMapByIds # 根据Id查询，返回Map pro.shushi.pamirs.core.common.FetchUtil#fetchListByIds # 根据Codes查询列表 pro.shushi.pamirs.core.common.FetchUtil#fetchMapByCodes # 根据Code查询，返回Map pro.shushi.pamirs.core.common.FetchUtil#fetchListByCodes # 根据Entity查询 pro.shushi.pamirs.core.common.FetchUtil#fetchOne 其他更多方法参考这个类的源代码 3.2 ListUtils pro.shushi.pamirs.meta.common.util.ListUtils # 把输入的List，按给定的长度进行分组 pro.shushi.pamirs.meta.common.util.ListUtils#fixedGrouping # 从给定的List中返回特定字段的数组，忽略Null并去重 pro.shushi.pamirs.meta.common.util.ListUtils#transform 4、枚举获取 根据枚举的name获取valueInteger value = ArchivesConfigTypeEnum.getValueByName(ArchivesConfigTypeEnum.class,“status1”);根据枚举的name获取枚举项ArchivesConfigTypeEnum typeEnum = TtypeEnum.getEnum(ArchivesConfigTypeEnum.class, “status1”); 5、Map类型的数据怎么定义，即ttype 为map的字段写法 @Field(displayName = "上下文", store = NullableBoolEnum.TRUE, serialize = JSON) @Field.Advanced(columnDefinition = "TEXT") private Map<String, Object> context; 6、后端获取前端请求中的variables PamirsRequestVariables requestVariables = PamirsSession.getRequestVariables(); 7、为什么有时候调用服务走远程了 1、假设： A模型（modelA）所在的模块（ModuleA） B模型（modelB）所在的模块（ModuleB） 部署方式决定调用方式： 1）部署方式1： ModuleA 和 ModuleB 部署在一个jvm中，此时： modelA的服务/页面去调用 modelB，因为部署在一起，直接走inJvm 2、部署方式2： ModuleA 和 ModuleB 部署在不同的jvm中； modelA的服务/页面去调用 modelB，则会走远程(RPC)；此时需要： a）ModuleB 需要开启dubbo服务，且ModuleA 和 ModuleB注册中心相同…

1、后台创建task type相关的类，继承BaseScheduleNoTransactionTask，要加springbean的注解，参考：task type建议使用类名 2、提交任务的时候，设置tasktype为步骤1的TaskType 3、控制台新增策略和任务bean名称为步骤1的spring beanName，任务名称 $xxx，右边的占位符内容为yml里面配置的ownSign字段任务的名称也是步骤1的 spring beanName 4、配置完成后，控制台启动任务，就可以测试了

1、非存储字段搜索 1.1 描述 通常根据本模型之外的信息作为搜索条件时，通常会把 这些字段放在代理模型上。这类场景我们称之为 非存储字段搜索 1.2 场景一 非存储字段为基本的String。1.代码定义：非存储字段为基本的包装数据类型 @Field(displayName = "确认密码", store = NullableBoolEnum.FALSE) private String confirmPassword; 2.设计器拖拽：列表中需要有退拽这个字段，字段是否隐藏的逻辑自身业务是否需要决定。3.页面通过非存储字段为基本的包装数据类型进行搜索时。会拼在 queryWrapper 的属性queryData中，queryData为Map，key为字段名，value为搜索值。4.后台逻辑处理代码示例： Map<String, Object> queryData = queryWrapper.getQueryData(); if (null != queryData) { Object productIdObj = queryData.get(PRODUCT_ID); if (Objects.nonNull(productIdObj)) { String productId = productIdObj.toString(); queryWrapper.lambda().eq(MesProduceOrderProxy::getProductId, productId); } } 1.3 场景二 非存储字段为非存储对象。 定义 为非存储的 @Field(displayName = "款", store = NullableBoolEnum.FALSE) @Field.many2one @Field.Relation(store = false) private MesProduct product; 2.页面在搜索栏拖拽非存储字段作为搜索条件 3.后台逻辑处理代码示例： try { if (null != queryData && !queryData.isEmpty()) { List<Long> detailId = null; BasicSupplier supplier = JsonUtils.parseMap2Object((Map<String, Object>) queryData.get(supplierField), BasicSupplier.class); MesProduct product = JsonUtils.parseMap2Object((Map<String, Object>) queryData.get(productField), MesProduct.class); MesMaterial material = JsonUtils.parseMap2Object((Map<String, Object>) queryData.get(materialField), MesMaterial.class); if (supplier != null) { detailId = bomService.queryBomDetailIdBySupplierId(supplier.getId()); if (CollectionUtils.isEmpty(detailId)) { detailId.add(-1L); } } if (product != null) { List<Long> produceOrderId = produceOrderService.queryProductOrderIdByProductIds(product.getId()); if (CollectionUtils.isNotEmpty(produceOrderId)) { queryWrapper.lambda().in(MesProduceBomSizes::getProduceOrderId, produceOrderId); } } if (material != null) { //找出两个bom列表的并集 List<Long> materBomDetailId = bomService.queryBomDetailIdByMaterialId(material.getId()); if (CollectionUtils.isNotEmpty(detailId)) { detailId = detailId.stream().filter(materBomDetailId::contains).collect(Collectors.toList()); } else { detailId = new ArrayList<>(); if (CollectionUtils.isEmpty(materBomDetailId)) { detailId.add(-1L); } else { detailId.addAll(materBomDetailId); } } } if (CollectionUtils.isNotEmpty(detailId)) { queryWrapper.lambda().in(MesProduceBomSizes::getProductBomId, detailId); } } } catch (Exception e) { log.error("queryData处理异常", e); } 注意:…

左树右表俩种情况 假设存在 A模型 B模型 1: 左树为A模型,右表为B模型 举例 A模型为类目 B模型为类目属性模型代码实例： @Model.model(AriesPlatformCategory.MODEL_MODEL) @Model(displayName = "平台后台类目", labelFields = "name") @Model.Advanced(type = ModelTypeEnum.PROXY) public class AriesPlatformCategory extends AriesCategory { public static final String MODEL_MODEL = "aries.item.AriesPlatformCategory"; @Field.many2one @Field.Relation(relationFields = {"parentCateCode"}, referenceFields = {"code"},store = true) @Field(displayName = "平台父类目") private AriesPlatformCategory platformCategory; @Field.one2many @Field(displayName = "类目属性") @Field.Relation(relationFields = "code", referenceFields = "categoryCode", store = true) private List<AriesPlatformCategoryAttr> platformCategoryAttrs; } @Model.model(AriesPlatformCategoryAttr.MODEL_MODEL) @Model(displayName = "Aries_平台类目属性", labelFields = "name") @Model.Advanced(type = ModelTypeEnum.PROXY) public class AriesPlatformCategoryAttr extends CategoryAttr { public static final String MODEL_MODEL = "aries.item.AriesPlatformCategoryAttr"; @Field.many2one @Field(displayName = "平台后台类目") @Field.Relation(relationFields = "categoryCode", referenceFields = "code", store = true) private AriesPlatformCategory platformCategory; } 在设计器设计左树右表之前，需要在模型 中配置好关联关系 。如下部分代码 配置好类目与父类目的关联关系。 @Field.many2one @Field.Relation(relationFields = {"parentCateCode"}, referenceFields = {"code"},store = true) @Field(displayName = "平台父类目") private AriesPlatformCategory platformCategory; 配置好 类目与类目属性的关联关系。一个类目可以有多个类目属性，一对多one2many @Field.one2many @Field(displayName = "类目属性") @Field.Relation(relationFields = "code", referenceFields = "categoryCode", store = true) private List<AriesPlatformCategoryAttr> platformCategoryAttrs; 在类目属性模型中，配置好属性与类目的关联关系，一个类目属性只属于一个类目，一个类目可以有多个类目属性。类目属性对类目多对一many2one @Field.many2one @Field(displayName = "平台后台类目") @Field.Relation(relationFields = "categoryCode", referenceFields = "code", store = true) private AriesPlatformCategory platformCategory; 设计器实例:1.需要选择 平台类目属性 做为主模型创建树表页面2.构建关联关系 选择平台后台类目 第一级的筛选条件 上级编码为空 表格关联关系字段 选择 平台类目属性。 3.表格拖拽好需要的属性字段 2: 左树为A模型,右表也为A模型 举例 左A模型 组织结构管理 右A模型 组织结构管理模型代码实例： @Model.model(BasicOrg.MODEL_MODEL) @Model(displayName = "组织结构管理", summary…

分布式调用下的[强制]约束 1、[强制]分布式调用情况下base库和redis需共用；2、[强制]如果环境有设计器，设计器的base库和redis保持一致也需与项目中的保持一致；3、[强制]相同base库下，不同应用的相同模块的数据源需保持一致；4、[强制]项目中需引入分布式缓存包。参考下文的分布式包依赖 分布式支持 1、分布式包依赖 1) 父pom的依赖管理中先加入pamirs-distribution的依赖 <dependency> <groupId>pro.shushi.pamirs</groupId> <artifactId>pamirs-distribution</artifactId> <version>${pamirs.distribution.version}</version> <type>pom</type> <scope>import</scope> </dependency> 2) 启动的boot工程中增加pamirs-distribution相关包 <!– 分布式服务发布 –> <dependency> <groupId>pro.shushi.pamirs.distribution</groupId> <artifactId>pamirs-distribution-faas</artifactId> </dependency> <!– 分布式元数据缓存 –> <dependency> <groupId>pro.shushi.pamirs.distribution</groupId> <artifactId>pamirs-distribution-session</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.distribution</groupId> <artifactId>pamirs-distribution-gateway</artifactId> </dependency> 3）启动工程的Application中增加类注解@EnableDubbo @EnableDubbo public class XXXStdApplication { public static void main(String[] args) throws IOException { StopWatch stopWatch = new StopWatch(); stopWatch.start(); // ……………………………… log.info("XXXX Application loading…"); } } 2、修改bootstrap.yml文件 注意序列化方式：serialization: pamirs 以下只是一个示例（zk为注册中心），注册中心支持zk和Nacos；Nacos作为注册中心参考：https://doc.oinone.top/kai-fa-shi-jian/5835.html spring: profiles: active: dev application: name: pamirs-demo cloud: service-registry: auto-registration: enabled: false pamirs: default: environment-check: true tenant-check: true — spring: profiles: dev cloud: service-registry: auto-registration: enabled: false config: enabled: false uri: http://127.0.0.1:7001 label: master profile: dev nacos: server-addr: http://127.0.0.1:8848 discovery: enabled: false namespace: prefix: application file-extension: yml config: enabled: false namespace: prefix: application file-extension: yml dubbo: application: name: pamirs-demo version: 1.0.0 registry: address: zookeeper://127.0.0.1:2181 protocol: name: dubbo port: -1 serialization: pamirs scan: base-packages: pro.shushi cloud: subscribed-services: metadata-report: disabled: true 3、模块启动的最⼩集 pamirs: boot: init: true sync: true modules: – base – 业务工程的Module 4、业务模型间的依赖关系 服务调用方(即Client端)，在启动yml中modules不安装服务提供方的Module 服务调用方(即Client端)，项目的pom中只依赖服务提供方的API（即模型和API的定义） 服务调用方(即Client端)，项目模块定义（即模型Module定义），dependencies中增加服务提供方的Modeule. 如下面示例代码中的FileModule @Module( name = DemoModule.MODULE_NAME, displayName = "oinoneDemo工程", version = "1.0.0", dependencies = {ModuleConstants.MODULE_BASE, CommonModule.MODULE_MODULE, FileModule.MODULE_MODULE, SecondModule.MODULE_MODULE/**服务提供方的模块定义*/ } ) 服务调用方(即Client端)，启动类的ComponentScan需要配置服务提供方API定义所在的包. 如下面示例中的：pro.shushi.pamirs.second…

项目工程管理 项目工程顶层分层 项目分层设计，划分出 CDM层、 标准业务层 、定制业务层； 沉淀领域业务模型至CDM层； 沉底业内通用功能至标准业务层； 客户定制化功能在定制业务层； 项目内部的层级划分 项目包结构管理及规范 pamirs-demo-api constant【常量的包路径】 enums【枚举类的包路径】 model【该领域核⼼模型的包路径】 pmodel【该领域代理模型的包路径】 tmodel【该领域传输模型的包路径】 service【存放该领域的⾮存储模型如：⽤于传输的临时模型】 utils【工具类】 XXModule【该类是Demo模块的定义】 pamirs-demo-core service【接口实现类】 init【模块初始化⼯作的包路径】 manager 【manager是 service的⼀些公共逻辑，不会定义为独⽴的function的类】 pamirs-demo-view（可选） action【模型对外交互的⾏为的包路径】 项目中模块间依赖 禁止出现api模块依赖core模块的情况，api模块只允许依赖api模块； 根据当前项目结构进行模块划分，避免循环依赖； 规划项目模块 项目阶段，代码开发前，业务架构师需充分的理解需求和蓝图，对系统进行业务域, 功能域的划分；例如：对一个电商系统： 提高系统的可维护性：通过将系统拆分为不同的业务域，每个业务域都有清晰的边界和职责，可以独立开发、测试和维护； 提升开发效率：业务域划分可以使开发团队更加专注于自己负责的业务，减少不必要的沟通和协调，提升开发效率； 促进团队合作：通过业务域划分，每个团队可以负责一个或多个业务域，团队成员之间可以有更高效的合作和协同。 支持系统的扩展和演化：业务域划分可以使系统更加灵活和可扩展。当需要新增一个新的业务功能或调整现有的业务逻辑时，只需要修改对应的业务域，而不需要对整个系统进行改动。 项目文档管理 项目文档管理对于项目的实施,项目进度管理，项目后期维护等都是至关重要的。系统详细的产品文档，测试文档，运维文档，开发文档，项目管理文档等。 协同合作：团队成员可以共享和访问项目文档，促进协同合作和信息共享，避免信息孤岛和重复工作。 知识管理：项目中所获得的知识，对项目的成功和后续的知识积累至关重要。通过良好的文档管理，可以确保项目知识的保存和传承，提高组织的知识管理能力。 问题解决：项目文档中记录了项目的需求、决策、问题和解决方案等信息。当出现问题或需要做决策时，可以通过查阅文档来获取相关信息，加快问题解决的速度，并减少错误和重复。 项目追踪：通过文档管理，可以跟踪项目的进展和状态。可以记录项目的里程碑、任务分配、进度更新等信息，帮助团队了解项目的整体情况，及时发现和解决问题。 知识共享：好的文档管理可以促进知识共享和传播。通过将项目文档进行分类、索引和存档，可以使团队成员更容易找到所需的信息，并从中学习和借鉴经验，提高工作效率和质量。 数据库和事务 多表联合查询 减少需要join的操作出现 用多次查询替代 索引相关 核心业务访问DB的Sql 要命中或者覆盖索引，保存核心业务的响应时间； 控制单表的索引数量，注意联合索引 数据一致性：乐观锁控制，unique�等 事务代码示例 事务相关注意点参考【Oinone如何支持构建分布式项目】：https://doc.oinone.top/kai-fa-shi-jian/5572.html

模型字段规范 配置注解 模型类必需使用@Model注解来标识当前类为模型类。可以使用@Model.model、@Fun注解模型的模型编码（也表示命名空间），先取@Model.model注解值，若为空则取@Fun注解值，若皆为空则取全限定类名。使用@Model.model注解配置模型编码，模型编码唯一标识一个模型。请勿使用Query和Mutation作为模型编码和技术名称的结尾。更多Model的详细元数据描述介绍参见模型元数据详解 模型命名规范 模型属性 默认取值规范 命名规则规范 name 默认取model.model的点分割最后一位 1. 使用大驼峰命名法 2. 仅支持数字、字母 3. 必须以字母开头 4. 长度必须小于等于128个字符 module 无默认值开发人员定义规范示例：{项目名称}_{模块功能示意名称} 1. 使用下划线命名法 2. 仅支持数字、大写或小写字母、下划线 3. 必须以字母开头4. 不能以下划线结尾 5. 长度必须小于等于128个字符 model 默认使用全类名，取lname的值开发人员定义规范示例：{项目名称}.{模功能示意名称}.{简单类名} 1. 仅支持数字、字母、点 2. 必须以字母开头 3. 不能以点结尾 4. 长度必须小于等于128个字符 displayName 空字符串 1. 长度必须小于等于128个字符 lname 符合java命名规范，真实的java全类名，无法指定，要符合model的约束，即为包名+类名 lname是不能定义的，为全类名：包名+类名，和model一样的校验规则：包名和类名的校验 summary 默认使用displayName属性 1. 不能使用分号 2. 长度必须小于等于128个字符 descripition NULL，注解无法定义 1. 长度必须小于等于65535个字符 table 默认使用name字段生成表名时，table字段的命名规则约束同样生效（大小驼峰命名转为下划线分割的表名称） 1. 仅支持数字、字母、下划线 2. 长度必须小于等于128个字符（此限制为系统存储约束，与数据库本身无关） type java属性类型与数据库存储类型可执行转换即可 ModelTypeEnum枚举值 字段命名规范 字段属性 默认取值规范 命名规则规范 name 默认使用java属性名 1. 仅支持数字、字母 2. 必须以小写字母开头 3. 长度必须小于等于128个字符 field 默认使用java属性名 与name使用相同命名规则约束 displayName 默认使用name属性 1. 长度必须小于等于128个字符 lname 使用java属性名，符合java命名规范，真实的属性名称，无法指定 与name使用相同命名规则约束 column 列名为属性名的小驼峰转下划线格式 1. 仅支持数字、字母、下划线 2. 长度必须小于等于128个字符（此限制为系统存储约束，与数据库本身无关） summary 默认使用displayName属性 1. 不能使用分号 2. 长度必须小于等于500个字符 模型继承规范 继承方式 继承方式可以分为五种： 抽象基类ABSTRACT，只保存不希望为每个子模型重复键入的信息的模型，抽象基类模型不生成数据表存储数据，只供其他模型继承模型可继承域使用，抽象基类可以继承抽象基类。 扩展继承EXTENDS，子模型与父模型的数据表相同，子模型继承父模型的字段与函数。存储模型之间的继承默认为扩展继承。 多表继承MULTI_TABLE，父模型不变，子模型获得父模型的可继承域生成新的模型；父子模型不同表，子模型会建立与父模型的一对一关联关系字段（而不是交叉表），使用主键关联，同时子模型会通过一对一关联关系引用父模型的所有字段。多表继承父模型需要使用@Model.MultiTable来标识，子模型需要使用@Model.MultiTableInherited来标识。 代理继承PROXY，为原始模型创建代理，可以增删改查代理模型的实体数据，就像使用原始（非代理）模型一样。不同之处在于代理继承并不关注更改字段，可以更改代理中的元信息、函数和动作，而无需更改原始内容。一个代理模型必须仅能继承一个非抽象模型类。一个代理模型可以继承任意数量的没有定义任何模型字段的抽象模型类。一个代理模型也可以继承任意数量继承相同父类的代理模型。 临时继承TRANSIENT，将父模型作为传输模型使用，并可以添加传输字段。 继承约束 通用约束 对于扩展继承，查询的时候，父模型只能查询到父模型字段的数据，子模型可以查询出父模型及子模型的字段数据（因为派生关系所以子模型复刻了一份父模型的字段到子模型中）。系统不会为抽象基类创建实际的数据库表，它们也没有默认的数据管理器，不能被实例化也无法直接保存，它们就是用来被继承的。抽象基类完全就是用来保存子模型们共有的内容部分，达到重用的目的。当它们被继承时，它们的字段会全部复制到子模型中。系统不支持非jar包依赖模型的继承。多表继承具有阻断效应，子模型无法继承多表继承父模型的存储父模型的字段，需要使用@Model.Advanced注解的inherited属性显示声明继承父模型的父模型。但是可以继承多表继承父模型的抽象父模型的字段。可以使用@Model.Advanced的unInheritedFields和unInheritedFunctions属性设置不从父类继承的字段和函数。 跨模块继承约束 如果模型间的继承是跨模块继承，应该与模型所属模块建立依赖关系；如果模块间有互斥关系，则不允许建立模块依赖关系，同理模型间也不允许存在继承关系。跨模块代理继承，对代理模型的非inJvm函数调用将使用远程调用方式；跨模块扩展（同表）继承将使用本地调用方式，如果是数据管理器函数，将直连数据源。 模型类型与继承约束 抽象模型可继承：抽象模型（Abstract） 临时模型可继承：抽象模型（Abstract）、传输模型（Transient） 存储模型可继承：抽象模型（Abstract）、存储模型（Store）、存储模型（多表，Multi-table Store），不可继承多个Store或Multi-table Store 多表存储模型（父）可继承：同扩展继承 多表存储模型（子）在继承单个Multi-table Store后可继承：抽象模型（Abstract）、存储模型（Store），不可继承多个Store 代理模型可继承： 抽象模型（Abstract），须搭配继承Store、Multi-table Store或Proxy 存储模型（Store），不可继承多个Store或Multi-table Store 存储模型（多表，Multi-table Store），不可继承多个Store或Multi-table Store 代理模型（Proxy），可继承多个Proxy，但多个父Proxy须继承自同一个Store或Multi-table Store，且不能再继承其他Store或Multi-table Store 同名字段以模型自身字段为有效配置，若模型自身不存在该字段，继承字段以第一个加载的字段为有效配置，所以在多重继承的情况下，未避免继承同名父模型字段的不确定性，在自身模型配置同名字段来确定生效配置。 相关链接：模型的继承 字段序列化方式 字段序列化注意点 必须使用Field#store属性将字段存储设置为NullableBoolEnum.TRUE。 使用Field#serialize属性指定序列化方式，默认为JSON。 如把PetItemDetail设置为存储模型，须在PetItem的petItemDetails字段上使用Field.Relation#store属性将关联关系存储设置为false。不然会同时存储petItemDetails字段和对应的PetItemDetail表记录 字段序列化方式说明 序列化方式 说明 备注 JSON JSON序列化 主要用于模型相关类型字段的序列化，是@Field.serialize默认选项 DOT 点拼接集合元素 COMM 逗号拼接集合元素 BIT 按位与，2次幂数求和 非@Field.serialize可选项列表，用于二进制枚举序列化不需要配置，由oinone自动推断 函数命名规范 模型属性 默认取值规范 命名规则规范 namespace 先取@Model.model注解值，先在本类查找注解，如果本类未配置或注解值为空则在父类或接口上查找；若为空则取@Fun注解值，先在本类查找注解，如果本类未配置或注解值为空则在父类或接口上查找；若皆为空则取全限定类名 长度必须小于等于128个字符 name 默认使用java方法名 仅支持数字、字母；必须以字母开头；长度必须小于等于128个字符；不能以get、set为开头作为函数名称 fun 默认使用name属性 长度必须小于等于128个字符 summary 默认使用displayName属性 不能使用分号；长度必须小于等于500个字符 descripition NULL，注解无法定义 长度必须小于等于65535个字符 openLevel 函数的开放等级默认值：{FunctionOpenEnum.LOCAL, FunctionOpenEnum.REMOTE} FunctionOpenEnum枚举值；LOCAL(2L, "本地调用", "本地调用"), REMOTE(4L, "远程调用", "远程调用"),…

标品工程结构 定制工程结构 leo-lb ## 依赖项(放在dev依赖，开发阶段使用。定制组只能依赖npm包) leo-item leo-inventory leo-user leo-basic leo-oinone 目录结构 src field -客户自定义字段 action -客户自定义动作 mask -客户自定义菜单、顶部栏等 layout -客户自定义布局 view -客户自定义页面 leo-lb-sdk ## 依赖项(放在dev依赖，开发阶段使用。定制组只能依赖npm包) leo-admin-sdk 目录结构 src field -客户自定义和无代码结合字段 定制部署 leo-boot 拉取releases/leo-lb分支发布至客户生产 ## 依赖项 leo-item leo-inventory leo-user leo-basic leo-oinone leo-admin-sdk leo-lb leo-lb-sdk 标品部署 leo-boot 拉取releases/leo分支发布至标品环境 ## 依赖项 leo-item leo-inventory leo-user leo-basic leo-oinone leo-admin-sdk

1.项目总体架构 Oinone总体工程架构 Oinone总体项目分层 以常见的B2C和全渠道订单OMS为例分层说明：1、最底层LCDP是低代码开发框架，提供低代码的开发能力；2、CDM通用数据模型层，主要解决系统间的数据标准；3、标品-标准业务产品层, 这层是我们核心的功能层，大部分业务代码都在这里完成；为了达到能按照模块组装的功能，标品需划分好模块，各模块是相对独立的服务(类似微服务的一个服务中心);4、客户定制层，可以对标品某个模块进行扩展，也可以新建模块；对标品扩展方式, 通常有以下几种方式：1）继承标品功能进行扩展2）覆盖方式，重写某个功能3）通过扩展点的方式注入定制逻辑4）通过SPI的方式，替换掉默认逻辑 2、设计器与应用 本地开发环境和开发环境，同一个环境下，有业务应用和设计器的两个入口，需要业务应用和设计器进行实时联动的情况，则要求：1.1 所有的【业务应用】和【设计器】，共用base库和基础数据的库； 业务应用的【业务数据】使用各自的业务库(可多个)；1.2 业务应用和设计器之间的互通通过配置网关(如Nginx等)的路由方式； 开发本地或者开发环境，若通过【业务的前端】入口直接访问到设计器，则需在【业务应用】的网关路由配置【设计器】的路由。 开发本地或者开发环境，若通过【设计器的前端】入口直接访问到业务系统，则需在【设计器】的网关路由配置【业务应用】的路由。 1.3 基础应用和业务应用、基础数据和设计器包含在一起，通过指定基础应用模块到对应的数据源的方式实现基础数据共享；1.4 基础应用(文件file/用户权限/资源等)单独部署；业务应用和设计器通过远程方式(RPC)进行调用； 2.1 模式一,应用和基础模块独立 总体方案：1、DB层面每个环境共用base库；主数据(用户、权限、资源等)单独建立主数据库；各自业务系统（包括设计器本身）建立自己的业务库。2、应用层面1）应用和设计器之间通过路由转发的方式相互访问；2）应用单独部署的情况，应用之间通过RPC(Dubbo)的方式进行调用；3）所有的应用AllinOne的方式部署在一起，则直接走SpringBean的方式(Injvm)； 2.1.1 模式1,DB划分 2.1.2 模式1,服务调用 2.2 模式二,应用和基础模块合并 3、部署架构图 4、Oinone项目包分层示例 4.1 CDM层示例 CDM层主要定义模型，包括模型之间的关系；对于主数据类的基础服务，可以确定上层不会修改的，也可包含这部分的服务层。 4.2 标品项目示例 ├── pamirs-boot 应用启动模块,启动入口,启动过程中系统性的数据初始化│ │ └── boot 启动类的包路径│ │ └── XxxApplication 模块的应用启动类，遵循spring boot 规范│ │ └── resources/config/application-dev.yml 研发环境的yml配置文件，遵循spring boot 规范│ │ └── resources/bootstrap.yml 启动的yml配置文件，遵循spring boot 规范├── pamirs-common 通用模块 工程通用常量,传输模型,Utils等├── pamirs-major 主数据模块│ ├── pamirs-major-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── constant 常量的包路径│ │ └── enums 枚举的包路径│ │ └── model 该领域核心模型的包路径│ │ └── service 该领域对外暴露接口api的包路径│ │ └── tmodel 存放该领域的非存储模型如：用于传输的临时模型│ │ └── MajorModule 该类是Major模块的定义│ ├── pamirs-major-core api的内部逻辑实现包│ │ └── init 模块初始化工作的包路径│ │ └── manager manager是 service的一些公共逻辑，不会定义为独立的function的类│ │ └── service service是对应api工程中service接口的实现类，是模型的function├── pamirs-eip 集成模块│ ├── pamirs-eip-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── EipModule 该类是Major模块的定义│ ├── pamirs-eip-core api的内部逻辑实现包├── pamirs-item 商品模块│ ├── pamirs-item-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── ItemModule 该类是Major模块的定义│ ├── pamirs-item-core api的内部逻辑实现包│ ├── pamirs-item-view 应用PC端│ │ └── action 模型对外交互的行为的包–对前端页面开放的接口│ │ └── init 模块初始化工作的包路径│ │ └── manager manager是 service的一些公共逻辑，不会定义为独立的function的类 4.3 系统的分层 himalaya(cdm) — himalaya-major — himalaya-common — himalaya-item — himalaya-inventory — himalaya-trade — …… kailas-leo（标品项目） — kailas-leo-major — kailas-leo-item — kailas-leo-trade — kailas-leo-pay — kailas-leo-boot — …… kailas-leo-lb（客户项目）…