Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9332.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
相关推荐
-
4.1.7 函数之元数据详解
介绍Function相关元数据，以及对应代码注解方式。大家还是可以通读下，以备不时之需 如您还不了解Function的定义，可以先看下2.3【oinone独特之源，元数据与设计原则】对Function的描述，本节主要带大家了解Function元数据构成，能让小伙伴非常清楚oinone从哪些维度来描述Function， 一、元数据说明 FunctionDefinition 元素数据构成 含义 对应注解 备注 namespace 函数命名空间 @Fun("") @Model.model("") @Fun或@Model.model name 技术名称 @Function( name=””, scene={}, summary=””, openLevel=FunctionOpenEnum.REMOTE ) scene 可用场景 见：FunctionSceneEnum description 描述 openLevel 开放级别 见：FunctionOpenEnum fun 编码 @Function.fun("") displayName 显示名称 @Function.Advanced( displayName=””, type=FunctionTypeEnum.UPDATE, dataManager=false, language=FunctionLanguageEnum.JAVA, isBuiltin=false, category=FunctionCategoryEnum.OTHER, group=”pamirs”, version=”1.0.0″, timeout=5000, retries=0, isLongPolling=false, longPollingKey=”userId” longPollingTimeout=1 ) type 函数类型默认：4(改) 见 FunctionTypeEnum dataManager 数据管理器函数默认：false language 函数语言默认：DSL 见FunctionLanguageEnum isBuiltin 是否内置函数 默认：false category 分类 默认：OTHER 见：FunctionCategoryEnum group 系统分组 默认：pamirs version 系统版本 默认：1.0.0 timeout 超时时间 默认：5000 retries 重试次数 默认：0 isLongPolling 是否支持long polling，默认false longPollingKey 支持从上下文中获取字段作为key longPollingTimeout long polling超时时间 默认值为1 transactionConfig 事务配置 JSON存储 见TransactionConfig 配置@PamirsTransactional source 来源 系统推断值，见：FunctionSourceEnum extPointList 函数包含扩展点 系统推断值 module 所属模块 系统推断值 bitOptions 位 系统推断值 attributes 属性 系统推断值 imports 上下文引用 系统推断值 context 上下文变量 系统推断值 codes 函数内容 系统推断值 beanName bean名称 系统推断值 rule 前端规则 系统推断值，一般Action.rule传递下来的 clazz 函数位置 系统推断值 method 函数方法 系统推断值 argumentList 函数参数 系统推断值，List<Argument> returnType 返回值类型 系统推断值 表4-1-7-1 FunctionDefinition TransactionConfig 函数事务管理之配置项事务，具体事务使用详见4.1.8【函数之事务管理】一文。 元素数据构成 含义 对应注解 备注 transactionManager 事务管理器 @PamirsTransactional( transactionManager=””, enableXa=false, isolation=Isolation.DEFAULT, propagation=Propagation.REQUIRED, timeout=-1, readOnly=false, rollbackFor={}, rollbackForClassName={}, noRollbackFor={}, noRollbackForClassName={}, rollbackForExpCode={}, noRollbackForExpCode={} ) enableXa 分布式事务默认为false isolation 事务隔离级别 propagation 事务传递类型 timeout 过期时间 默认：-1 readOnly 只读 默认：false rollbackForExpCode 回滚异常编码 rollbackForExpCode 忽略异常编码 namespace 函数命名空间 系统推断值 fun 函数编码 系统推断值 active…
-
5.1 CDM的背景介绍
如果说低代码开发框架输出技术标准，CDM则是结合oinone技术特性和软件工程设计，让输出数据标准变成可能。 一、背景介绍 无法照搬的最佳实践 要了解引入CDM的初衷，得从互联网架构的演进开始，了解其过程，就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心！我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段，特别平台化到中台化的阶段，目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展，适用多业务线（或多场景应用）独立发展。 互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似： 随着企业业务在线化后对系统性能、稳定都提出了更高的要求，而且大部分企业的内部很多系统相互割裂导致，导致很多重复建设，所以我们需要服务化、平台化。 同时没有一个供应商能解决企业所有商业场景问题，又需要多个供应商共同参与，所以把供应商类类比成各个业务线，在一套规范下让供应商自行决定业务系统发展 既然跟阿里当初在架构演进过程中碰到的问题非常类似，那么是不是照搬阿里中台架构方案到企业就好了？当然不是，因为历史原因阿里的中台架构是采用的平台共建模式：“让业务线研发以平台设计好的规范进来共同开发”，其本质还是平台主导模式，它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台，那是多么荒唐的事情，平台化已经足够的复杂了，还让不同背景、不同企业的研发一起共建，最后往往导致企业架构负载过重，这时对企业来说便不再是赋能而是“内耗”。 那么如果没有历史包袱，我们重新设计，站在上帝视角去看有没有更好的方式呢？当然有 借鉴微软的CDM 这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。 数字化时代软件会产生新的技术流派 我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。 而Oinone的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合Oinone的低代码开发机制进行快速开发，灵活应对业务变化。 所以我更想说Oinone的CDM是微软CDM的在原有基础上，与互联网架构结合，利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致，支撑“所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主性，快速创新的能力。 图5-1-1 Oinone-CDM要解决的问题 二、Oinone的CDM本质是创新的工程化建议 引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。 原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。 互联网整体平台化带来的问题： 业务线每次业务调整都需要给各个平台提需求 业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高 各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性 结合oinone特性提出的新工程建议： 一些通用性模块继续以平台化的方式存在，能力完全复用。 业务线自建业务平台，保持业务线的独立性和敏捷性 业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范 图5-1-2 引入CDM概念后的工程结构对比 三、CDM思路示意图 该示例中OinoneCDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。 带来的好处： 通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。 通过CDM层统一数据模型，从而解决多应用数据割裂问题 图5-1-3 Oinone-CDM思路示意图
-
4.5.1 研发辅助之插件-结构性代码
研发辅助意在 消灭研发过程中的重复性工作提升研发效率，如结构性代码 提供生产示例性代码，如果根据模型生成导入导出、view自定义配置等经常性开发 一、插件安装 根据自身Idea版本下载插件并安装： 版本 插件 2023.1 pamirs-source-maker-1.0.0-2023.1.zip(2.4 MB) 2021.1 pamirs-source-maker-1.0.0-2021.1.zip(2.4 MB) 2021.2 pamirs-source-maker-1.0.0-2021.2.zip(2.4 MB) 2021.3 pamirs-source-maker-1.0.0-2021.3.zip(2.4 MB) 2022.1 pamirs-source-maker-1.0.0-2022.1.zip(2.4 MB) pamirs-source-maker-1.0.0-223-EAP-SNAPSHOT(2.4 MB) 表4-5-1-1 插件列表 二、研发辅助之配置式结构性代码生成器 我们在开发过程中为了日后代码易于维护和修改，往往会做工程性的职责划分。 除去模型外会有 代理模型和代理模型Action来负责前端交互 以面向接口的形式来定义函数，就会有api和实现类之分 如果项目有多端，那么如代理模型和代理模型Action又要为每一个端构建一份 在大型项目的初始阶段，我们需要手工重复做很多事情，特别麻烦。现在用oinone的研发辅助插件的结构性代码生成器，就可以避免前面的重复工作 插件执行的配置文件 <?xml version="1.0" encoding="utf-8" ?> <oinone> <makers> <!– 根据模型生成代理类、代理类的Action、Service、ServiceImpl –> <maker> <!– 选择模型所在位置 –> <modelPath>/Users/oinone/Documents/oinone/demo/pamirs-second/pamirs-second-api/src/main/java/pro/shushi/pamirs/second/api/model</modelPath> <!– 代理模型、代理模型Action生成相关配置信息 –> <proxyModules> <module> <!– 代理模型和代理模型Action的生成位置信息 –> <generatePath>/Users/oinone/Documents/oinone/demo/pamirs-second/pamirs-second-api/src/main/java/pro/shushi/pamirs/second/api</generatePath> <!– 代理模型和代理模型Action的模块前缀 –> <modulePrefix>second</modulePrefix> <!– 代理模型和代理模型Action的模块名，代理模型和代理模型Action类名为moduleName+模型名+"Proxy"+"Action" –> <moduleName>second</moduleName> <!– 代理模型和代理模型Action的包名,实际包名为 packageName+".proxy"或packageName+".action"–> <packageName>pro.shushi.pamirs.second.api</packageName> </module> </proxyModules> <!– 根据模型生成api，包括service（写方法）和queryService（读方法） –> <apiModule> <!– service和queryService的生成位置信息 –> <generatePath>/Users/oinone/Documents/oinone/demo/pamirs-second/pamirs-second-api/src/main/java/pro/shushi/pamirs/second/api</generatePath> <!– service和queryService的模块前缀 –> <modulePrefix>second</modulePrefix> <!– service和queryService的模块名 –> <moduleName>second</moduleName> <!– service和queryService的包名,实际包名为 packageName+".service" –> <packageName>pro.shushi.pamirs.second.api</packageName> </apiModule> <!– 根据模型生成api实现类，包括serviceImpl（写方法）和queryServiceImpl（读方法） –> <coreModule> <!– serviceImpl和queryServiceImpl的生成位置信息 –> <generatePath>/Users/oinone/Documents/oinone/demo/pamirs-second/pamirs-second-core/src/main/java/pro/shushi/pamirs/second/core</generatePath> <!– serviceImpl和queryServiceImpl的模块前缀 –> <modulePrefix>second</modulePrefix> <!– serviceImpl和queryServiceImpl的模块名 –> <moduleName>second</moduleName> <!– serviceImpl和queryServiceImpl的包名,实际包名为 packageName+".service" –> <packageName>pro.shushi.pamirs.second.core</packageName> </coreModule> </maker> </makers> </oinone> 图4-5-1-1 插件执行的配置文件 三、研发辅助之多模型结构性代码生成器 是配置式结构性代码生成器的补充，应对开发后期维护中新增模型的场景。它的不同点在于只要选择模型文件就可以，不需要专门编写xml文件。生成的文件默认就在模型所在路径下 Step1 菜单栏上找到oinone，并点击子菜单【多模型结构性代码生成器】 图4-5-1-2 多模型结构性代码生成操作步骤一 Step2 设置必要的信息 模型前缀 模型的所属模块 代理模型的模块 这三个信息分别用于构建 代理模型的MODEL_MODEL = 模型前缀.代理模型的模块.代理模型类名 服务的FUN_NAMESPACE = 模型前缀.代理模型的模块.服务类名 图4-5-1-3 多模型结构性代码生成操作步骤二 Step3 选择为哪些模型生成对应的结构性代码 图4-5-1-4 多模型结构性代码生成操作步骤三 Step4 代码在模型所在目录 生成的文件默认就在模型所在路径下，您可以手动拖动到对应的包路径当中去 图4-5-1-5 多模型结构性代码生成操作步骤四
-
集成平台
1. 集成介绍 集成是指平台应用与外部系统之间的集成，平台内部应用之间直接内部服务调用。 在讲解集成设计之前先了解以下概念： 集成资源：在实际业务场景中需要将多个系统打通，针对单一的一方，我们称之为集成资源。集成资源可以是具体的数据服务合集，例如系统应用、数据库、FTP服务、域控服务等。 连接器：连接具体集成资源，以供后续实际集成时使用的connector。 数据流程：通过流程编排的方式，让集成也可以可视化的处理，提升集成作业效率。 集成平台通过连接器、数据流程的编排实现与外部系统的数据互通，包括：连接器、数据流程、流程日志三部分功能。 集成操作整体流程： 2. 连接器 支持集成应用、数据库两大类型的资源。 页面操作包括：新增、编辑、查看引用、删除，点击卡片进入API列表管理接口。 2.1 连接器之应用 2.1.1 新增应用 操作入口：在连接器、应用Tab页面——新增应用资源。 2.1.2 编辑应用 编辑应用同新增页面信息，不做赘述。 2.1.3 删除应用 允许删除未被引用的应用，已被引用的不允许删除。 2.1.4 应用详情 点击应用卡片进入应用详情，查看应用基础信息、集成的接口清单。 2.1.5 API接口 操作入口：新增资源后，点击连接器卡片，进入API管理页面。 页面操作：新增、删除、编辑、详情、返回连接器。 2.1.5.1 新增API 输入基础信息、请求参数、定义响应结果； API URL支持： 协议类型：HTTP/HTTPS Verb：GET、POST、PUT、DELETE 参数类型支持：Long、Double、String、Boolean、Integer、Date、Void、Object。 2.1.5.2 新增WebService 输入基础信息、请求参数、定义响应结果； API URL支持： 协议类型：HTTP/HTTPS Verb：POST 参数类型支持：Long、Double、String、Boolean、Integer、Date、Void、Object。 2.1.5.3 编辑 编辑同新增页面信息，不做赘述。 2.1.5.4 删除 删除API接口后不能继续使用，请慎重。 2.1.6 查看引用 查看引用应用资源的接口。 2.2 连接器之资源 2.2.1 新增数据库资源 操作入口：在连接器页面，切换到数据库页面——新增DB资源。 2.2.2 编辑应用 编辑应用同新增页面信息，不做赘述。 2.2.3 删除应用 允许删除未被引用的应用，已被引用的不允许删除。 2.2.4 查看引用 查看引用数据库的接口。 2.2.5 数据库详情 点击应用卡片进入数据库连接器详情，查看应用基础信息、集成的接口清单，新增API。 2.2.6 API接口 2.2.6.1 新增API 输入基础信息、请求参数、数据库操作、定义响应结果。 2.2.6.2 编辑 编辑同新增页面信息，不做赘述。 2.2.6.3 删除 删除API接口后不能继续使用，请慎重。 3. 数据流程 3.1.1 数据流程介绍 数据流程：通过流程编排的手段，可视化的配置、处理集成的数据流程，提升集成作业效率。 主要包含基本操作和流程设计两个部分。前者包含了流程的新增、删除、复制、停用/启用、设计/编辑、搜索。后者包含单一流程的基础信息修改、流程设计、参数配置、保存、发布。 3.1.2 流程的基本操作 3.1.2.1 新增流程 新增流程，点击后进入流程设计页面，流程名默认为“未命名流程”，可自行修改。 3.1.2.2 设计/编辑 点击编辑进入该流程的设计页面。 3.1.2.3 停用/启用 流程需要更新或暂时不用时可以使用停用功能。流程停用后将不会执行流程，正在执行中的流程不受停用影响。 针对停用流程，点击启用按钮，流程恢复启用状态，可正常触发。 3.1.2.4 复制 遇到流程节点动作相似度较高的情况可以使用复制流程的功能，点击按钮后生成一个“原流程名-复制”的流程，并且进入新流程的流程设计界面。 3.1.2.5 删除 遇到流程创建有误，没有使用过且将来也不会使用该流程，可以删除流程。需要注意的是，删除流程的前提是该流程已停用，并且该流程从未执行过。 3.1.3 流程设计 通过新增、编辑/设计动作进入流程设计页后，可以进行流程名称、流程说明的编辑，可以进行流程设计，流程参数配置，保存和发布。 3.1.3.1 流程配置 点击进入流程配置页面，若需要配置一些参数供流程使用，可在此添加和删除。删除流程参数时，若该参数已在流程中被使用则无法删除。参数支持文本、数值、日期、布尔四种类型。 3.1.3.2 保存 点击后流程设计进行存档，流程设计不完整也支持保存，下次进入流程设计回到保存的页面。 3.1.3.3 发布 第一次发布时右上角发布显示文字为发布流程，后续发布按钮显示文字为更新发布。发布后流程才会按照设计触发，首次发布和更新发布的逻辑一致，若流程中有未解决的错误则无法发布不成功，发布成功后页面跳转到显示全部流程的页面，流程状态为已启用、已更新。 3.1.4 流程触发 新增的流程设计页面默认包含两个节点，一个是流程的触发节点：确定流程开始的条件；另一个是流程结束的节点。 流程触发方式有定时触发、消息触发两种方式，未设置流程触发方式时无法继续添加后续流程节点，同时无法进行流程发布，如左下图。触发方式设置完成后，可从左侧菜单栏拖入或流程箭头中的加号点击添加节点动作，如下图。 3.1.4.1 定时触发 定时触发适用于周期性调用流程的场景，设置流程第一次执行的时间，配置循环的周期间隔。 3.1.4.2 消息触发 消息触发方式下，识别消息任务的唯一标识，标识可复用。在发送消息时，必须匹配定义的消息标识。 3.1.5节点动作 3.1.5.1 集成服务 集成服务API，选择集成的应用、此应用下的API，配置相应的参数。 3.1.5.2 数据处理 【新增数据】节点：同流程设计器； 【更新数据】节点：同流程设计器； 【获取数据】节点：同流程设计器； 【删除数据】节点：同流程设计器； 【更新流程参数】节点：同流程设计器； 【引用逻辑】节点：同流程设计器； 3.1.5.3 构建 【延时】节点：同流程设计器； 【条件分支】节点：同流程设计器； 【子流程】节点：同流程设计器； 【循环】节点 循环模式：次数循环、列表循环； 次数循环：需配置循环开始值、循环结束值、循环步长； 列表循环：配置需要循环的列表； 均使用表达式配置相应字段， 3.1.5.4 通知消息 【站内信】节点：同流程设计器； 【邮件】节点：同流程设计器； 【短信】节点：同流程设计器； 4. 流程日志 查看流程执行的情况，包括执行状态、执行时间、执行时长，针对异常流程，可以重试。 详情：查看流程日志、日志详情。
-
4.4 Oinone的分布式体验进阶
在分布式开发中，每个人基本只负责自己相关的模块开发。所以每个研发就都需要一个环境，比如一般公司会有（N个）项目环境、1个日常环境、1个预发环境、1个线上环境。在整项目环境的时候就特别麻烦，oinone的好处是在于每个研发可以通过boot工程把需要涉及的模块都启动在一个jvm中进行开发，并不依赖任何环境，在项目开发中，特别方便。但当公司系统膨胀到一定规模，大到很多人都不知道有哪些模块，或者公司出于安全策略考虑，或者因为启动速度的原因（毕竟模块多了启动的速度也会降下来）。本文就给大家介绍oinone与经典分布式组织模式的兼容性 一、模块启动的最小集 我们来改造SecondModule模块，让该模块的用户权限相关都远程走DemoModule Step1 修改SecondModule的启动工程application-dev.yml文件 除了base、second_core两个模块保留，其他模块都去除了。 pamirs: boot: init: true sync: true modules: – base – second_core 图4-4-1 SecondModule的application-dev.yml仅配置两个模块 Step2 去除boot工程的依赖 去除SecondModule启动工程的pom依赖 <!– <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-resource-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-message-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-international</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-business-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-apps-core</artifactId> </dependency> –> 图4-4-2 去除boot工程多余的依赖 Step3 重启SecondModule 这【远程模型】和【远程代理】均能访问正常 图4-4-3 远程模型和远程代理菜单均能访问正常 Step4 SecondModule增加对模块依赖 我们让SecondModule增加用户和权限模块的依赖，期待效果是：SecondModule会对用户和权限的访问都会走Dome应用，因为Demo模块的启动工程中包含了user、auth模块。 修改pamirs-second-api的pom文件增加对user和auth的api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-api</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-api</artifactId> </dependency> 图4-4-4 修改pamirs-second-api的pom文件 修改SecondModule类，增加依赖定义 @Module( dependencies = {ModuleConstants.MODULE_BASE, AuthModule.MODULE_MODULE, UserModule.MODULE_MODULE} ) 图4-4-5 配置SecondModule的依赖 Step5 修改RemoteTestModel模型 为RemoteTestModel模型增加user字段 @Field.many2one @Field(displayName = "用户") private PamirsUser user; 图4-4-6 为RemoteTestModel模型增加user字段 Step6 重启系统看效果 mvn install pamirs-second工程，因为需要让pamirs-demo工程能依赖到最新的pamirs-second-api包 重启pamirs-second和pamirs-demo 两个页面都正常 图4-4-7 示例效果一 图4-4-8 示例效果二 二、PmetaOnline的NEVER指令（开发时环境共享） 我们在4.1.2【模块之启动指令】一文中介绍过 “-PmetaOnline指令”，该参数用于设置元数据在线的方式，如果不使用该参数，则profile属性的默认值请参考服务启动可选项。-PmetaOnline参数可选项为： NEVER – 不持久化元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为false MODULE – 只注册模块信息，会将pamirs.boot.options中的updateModule属性设置为true，reloadMeta和updateMeta属性设置为false ALL – 注册持久化所有元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为true oinone的默认模式下元数据都是注册持久化到DB的，但当我们在分布式场景下新开发模块或者对已有模块进行本地化开发时，做为开发阶段我们肯定是希望复用原有环境，但不对原有环境照成影响。那么-PmetaOnline就很有意义。让我们还没有经过开发自测的代码产生的元数据仅限于开发本地环境，而不是直接影响整个大的项目环境 PmetaOnline指令设置为NEVER（举例） Step1 为DemoCore新增一个DevModel模型 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(DevModel.MODEL_MODEL) @Model(displayName = "开发阶段模型",summary="开发阶段模型，当PmetaOnline指令设置为NEVER时，本地正常启动但元数据不落库",labelFields={"name"}) public class DevModel extends AbstractDemoCodeModel{ public static final String MODEL_MODEL="demo.DevModel"; @Field(displayName = "名称") private String name; } 图4-4-9 为DemoCore新增一个DevModel模型 Step2 为DevModel模型配置菜单 @UxMenu("开发模型")@UxRoute(DevModel.MODEL_MODEL) class DevModelProxyMenu{} 图4-4-10 为DevModel模型配置菜单 Step3 启动Demo应用时指定-PmetaOnline 图4-4-11 启动Demo应用时指定-PmetaOnline Step4 重启系统看效果 查看元数据 图4-4-12 DB查看元数据变化 菜单与页面能正常操作 图4-4-13 开发模型菜单可正常操作 图4-4-14 开发模型详情页面可正常操作 Step5 Never模式需注意的事项 业务库需设定为本地开发库，这样才不会影响公共环境，因为对库表结构的修改还是会正常进行的 如果不小心影响了公共环境，需要对公共环境进行重启恢复 系统新产生的元数据（如：例子中的【开发模式】菜单）不受权限管控 三、分布式开发约定 设计约定 跨模块的存储模型间继承，在部署时需要跟依赖模块配置相同数据源。这个涉及模块规划问题，比如业务上的user扩展模块，需要跟user模块一起部署。…