相关推荐

• Oinone 7天入门到精通

  3.5.7.5 自定义动作

  动作是什么 动作（action)描述了终端用户的各种操作。这些操作可以涉及多个层面，包括但不限于： 页面间的跳转：用户可以通过动作从一个页面跳转到另一个页面。 业务交互：动作可以触发与后端服务的交互，例如提交表单、请求数据等。 界面操作：动作可以用于打开模态对话框、抽屉（侧边栏）等界面元素。 作用场景 Oinone 平台内置了一系列的基础动作，默认实现了常见的功能，如页面跳转、业务交互和界面操作等。这些内置动作旨在满足大多数标准应用场景的需求，简化开发过程，提高开发效率。以下是一些常见的内置动作示例： 页面跳转：允许用户在不同页面间导航。 业务交互：支持与后端服务的数据交互，如提交表单。 界面操作：提供动态返回上一页、校验表单、关闭弹窗等。 自定义动作的需求场景 尽管内置动作覆盖了许多常规需求，但在某些复杂或特定的业务场景中，可能需要更加个性化的处理。这些场景可能包括： 特殊的业务逻辑：需要执行不同于标准流程的特定业务操作。 个性化的用户界面：标准的 UI 组件无法满足特定的设计要求。 高级交互功能：需要实现复杂的用户交互和数据处理。 扩展和定制动作 为了满足这些特定需求，Oinone 平台支持通过继承和扩展来自定义动作。开发者可以通过以下步骤实现自定义动作： 继承基类：从平台提供的动作基类继承，这为自定义动作提供了基础框架和必要的接口。 实现业务逻辑：在继承的基础上，添加特定的业务逻辑实现。 自定义界面：根据需要调整或完全重写界面组件，以符合特定的UI设计。 集成测试：确保自定义动作在各种情况下的稳定性和性能。 最佳实践 明确需求：在进行扩展之前，清楚地定义业务需求和目标。 重用现有功能：尽可能利用平台的内置功能和组件。 保持一致性：确保自定义动作与平台的整体风格和标准保持一致。 充分测试：进行全面的测试，确保新动作的稳定性和可靠性。 案例分析 假设有一个场景，需要一个特殊的数据提交流程，该流程不仅包括标准的表单提交，还涉及复杂的数据验证和后续处理。在这种情况下，可以创建一个自定义动作，继承基础动作类并实现特定的业务逻辑和用户界面。 自定义动作 自定义跳转动作 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./action，action/index.ts更新导出./custom-viewactioin： 图3-5-7-24 自定义跳转动作工程目录示例 步骤 1: 创建自定义动作类 首先，您创建了一个名为 CustomViewAction 的类，这个类继承自 RouterViewActionWidget。这意味着自定义动作是基于路由视图动作的，这通常涉及页面跳转或导航。 import {ActionWidget, RouterViewActionWidget, SPI} from '@kunlun/dependencies'; import CustomViewActionVue from './CustomViewAction.vue'; @SPI.ClassFactory( ActionWidget.Token({ model: 'resource.ResourceCity', name: 'redirectCreatePage' }) ) export class CustomViewAction extends RouterViewActionWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomViewActionVue); return this; } } 图3-5-7-24 自定义跳转动作组件(TS)代码示例 @SPI.ClassFactory: 这是一个装饰器，用于向平台注册这个新的动作。 ActionWidget.Token: 通过这个Token，指定了这个动作与特定模型 (resource.ResourceCity) 关联，并给这个动作命名 (redirectCreatePage). 步骤 2: 初始化和设置组件 在 initialize 方法中，调用了父类的初始化方法，并设置了自定义的 Vue 组件。 public initialize(props) { super.initialize(props); this.setComponent(CustomViewActionVue); return this; } 图3-5-7-24 初始化和设置组件 步骤 3: 定义 Vue 组件 在 CustomViewAction.vue 文件中，定义了自定义动作的视觉表示。 <template> <div class="view-action-wrapper"> 自定义挑战跳转动作 </div> </template> <script lang="ts"> import { defineComponent } from 'vue' export default defineComponent({ inheritAttrs: false, name: 'ViewActionComponent' }) </script> <style lang="scss"> .view-action-wrapper { } </style> 图3-5-7-24 自定义跳转动作组件(Vue)代码示例 步骤 4: 效果如下 图3-5-7-24 自定义跳转动作效果示例 自定义服务器动作 示例工程目录 以下是需关注的工程目录示例，action/index.ts更新导出./custom-serveraction： 图3-5-7-24 自定义服务器动作工程目录示例 步骤 1: 创建自定义动作类 首先, 创建了一个名为 CustomServerAction 的类，这个类继承自 ServerActionWidget。这表明您的自定义动作主要关注服务器端的逻辑。 import {ActionWidget, ServerActionWidget, SPI, Widget} from '@kunlun/dependencies'; import CustomServerActionVue from './CustomServerAction.vue'; @SPI.ClassFactory( ActionWidget.Token({ model: 'resource.ResourceCity', name: 'delete' })…

  史, 昂

  2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  3.5.7.2 自定义母版

  母版是什么 在业务系统中，母版是一种全局通用的组件，用于包裹每个页面的元素。这个概念类似于 PPT 中的母版，它定义了页面的整体结构、样式和布局，使得系统具有一致的外观和风格。 特点： 全局通用：母版是全局性的，适用于系统中的每个页面，确保一致性的用户体验。 包裹元素：母版包裹每个页面的元素，定义了整体的结构和布局。 外观一致性：通过统一的母版设计，系统达到外观和风格的一致性。 与 PPT 母版的类比： 在母版的概念上，与 PPT 中的母版类似，都是用于定义整体结构和样式，确保每个页面都具有一致的外观。 默认母版范围: 图3-5-7-20 默认母版范围 作用场景 在系统中，我们提供了多个纬度的母版，包括全局、应用和页面纬度。这样的设计允许根据不同的业务场景选择合适的母版纬度，以满足不同层次的定制需求。 母版纬度： 全局母版： 覆盖系统中所有页面，确保全局的一致性和统一的用户体验。 定义全局性的结构、样式和布局。 应用母版： 适用于特定应用或模块，定制化程度介于全局和页面之间。 允许在不同应用间实现一定的差异化。 页面母版： 面向具体页面，提供最大的定制化空间。 允许在不同页面中定义不同的结构和样式。 选择纬度： 业务场景决定：根据具体的业务场景和需求选择合适的母版纬度。 定制化需求：如果需要全局一致性，选择全局母版；如果在应用层面有特定需求，选择应用母版；如果需要最大的灵活性和定制化，选择页面母版。 参数说明： 在系统中，使用 registerMask 注册母版时，需要提供两个参数。第一个参数是母版的 XML，第二个参数用于控制母版的注册行为，包括 module、moduleName、model 和 actionName。 母版 XML（第一个参数）： 提供母版的 XML 描述，定义了母版的结构和样式。 控制参数（第二个参数）： module：指定模块的名称。 moduleName：指定模块的显示名称。 model：指定母版所属的模型。 actionName：指定母版的操作名称，可以是字符串或字符串数组。 全局母版 可以使用 registerMask 注册母版。当第二个参数为 {} 时，即代表注册全局母版。 示例工程目录 以下是需关注的工程目录示例，并确保导入导出依赖正确： 图3-5-7-21 全局纬度注册母版工程目录示例 示例代码 以下是一个示例代码： import { registerMask } from '@kunlun/dependencies'; /** * mask: 在做系统时，我们通常会把外层的布局(菜单、顶部导航)等抽出公共组件，公共组件会抽离全局通用。类似ppt母版的概念即为Mask * registerMask 第二个入参为{}即注册了全局得母版 * * 和默认母版相比移除右上角消息、语言切换、用户 * `<block> * <widget widget="notification" /> * <widget widget="divider" /> * <widget widget="language" /> * <widget widget="divider" /> * <widget widget="user" /> * </block>` */ const registerGlobalMask = () => { registerMask(` <mask> <multi-tabs /> <header> <widget widget="app-switcher" /> </header> <container> <sidebar> <widget widget="nav-menu" height="100%" /> </sidebar> <content> <breadcrumb /> <block width="100%"> <widget width="100%" widget="main-view" /> </block> </content> </container> </mask>`, {}); } registerGlobalMask(); 图3-5-7-22 全局纬度注册母版代码示例 复制这段代码执行下registerGlobalMask()试试看吧 效果 右上角消息、语言切换、用户被移除。 图3-5-7-23 全局纬度注册母版效果示例 应用母版 在系统中，可以使用 registerMask 注册母版。当第二个参数为 {moduleName: ‘resource’} 时，即注册了 resource（资源）应用的母版。 示例工程目录 以下是需关注的工程目录示例，更新导出./moduleMask： 图3-5-7-24 应用纬度注册母版工程目录示例 示例代码 以下是一个示例代码： /** * registerMask 第二个入参为{moduleName: 'resource'}即注册了resource(资源)应用的母版 * * resource来源: 通常是浏览器url上的module * * 和默认模版相比拿掉了菜单 * `<sidebar> * <widget widget="nav-menu" height="100%"…

  史, 昂

  2024年5月23日

  1.7K000
• Oinone 7天入门到精通

  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 多模型结构性代码生成操作步骤四

  史, 昂

  2024年5月23日

  1.4K000
• Oinone 7天入门到精通

  4.1.14 Search之非存储字段条件

  search默认查询的是模型的queryPage函数，但我们有时候需要替换调用的函数，这个特性会在下个版本支持。其核心场景为当搜索条件中有非存储字段，如果直接用queryPage函数的rsql拼接就会报错，所以非存储字段不会增加在rsql中。本文介绍一个比较友好的临时替代方案。 非存储字段条件（举例） Step1 为PetTalent新增一个非存储字段unStore @Field(displayName = "非存储字段测试",store = NullableBoolEnum.FALSE) private String unStore; 图4-1-14-1 为PetTalent新增一个非存储字段unStore Step2 修改PetTalent的Table视图的Template 在标签内增加一个查询条件 <field data="unStore" /> 图4-1-14-2 修改PetTalent的Table视图的Template Step3 重启看效果 进入宠物达人列表页，在搜索框【非存储字段测试】输入查询内容，点击搜索跟无条件一致 Step4 修改PetTalentAction的queryPage方法 package pro.shushi.pamirs.demo.core.action; …… 引入依赖类 @Model.model(PetTalent.MODEL_MODEL) @Component public class PetTalentAction { ……其他代码 @Function.Advanced(type= FunctionTypeEnum.QUERY) @Function.fun(FunctionConstants.queryPage) @Function(openLevel = {FunctionOpenEnum.API}) public Pagination<PetTalent> queryPage(Pagination<PetTalent> page, IWrapper<PetTalent> queryWrapper){ QueryWrapper<PetTalent> queryWrapper1 = (QueryWrapper<PetTalent>) queryWrapper; Map<String, Object> queryData = queryWrapper.getQueryData(); String unStore = (String) queryData.get(LambdaUtil.fetchFieldName(PetTalent::getUnStore)); if (StringUtils.isNotEmpty(unStore)) { //转换查询条件 queryWrapper1.like( 图4-1-14-3 修改PetTalentAction的queryPage方法 Step5 重启看效果 在搜索框【非存储字段测试】输入查询内容，跟通过【达人】字段搜索的效果是一致的 图4-1-14-4 示例效果

  史, 昂

  2024年5月23日

  1.9K000
• Oinone 7天入门到精通

  1.4 Oinone对软件特性的思考

  我在个人的微信公众号上《浅谈企业IT架构的十年困局》一文中写了“企业或者软件公司在工程领域都关注哪些特征，而这些特征又应与具体研发人员的个体能力无关”的相关内容。收到很多业内人士的留言，也引起了很多同行的共鸣，所以今天在这里也打算针对这个话题，跟大家再做个深入的探讨。 一、首先为什么强调要跟研发个体能力无关 我们先来看一个故事： 轮扁是春秋时期齐国的木工，齐桓公召其入宫打造物件。有一天，齐桓公在堂上看书，轮扁在堂下用椎、凿等工具做车轮。 齐桓公看书看到得意处，不由得读出声来。轮扁听到读书声，想了想，放下手里的工具，走上堂来，在齐桓公面前几步远的地方停下，恭恭敬敬地说：“请恕臣斗胆问一下，君王读的是什么书？”齐桓公没想到这个老木匠会走上堂来，倒有点意外。不过看在他年纪大的份上，倒也不去斥责他，就回答说：“寡人读的是圣人写的书。”轮扁问：“圣人还在吗？”齐桓公说：“已经死了。”轮扁说：“这样看起来，君王所读的，不过是古人的糟粕而已！”齐桓公勃然大怒，说：“寡人读书，你一个做车轮的怎么敢议论？你说，这书上怎么会是古人的糟粕？说出道理便罢，说不出道理便难逃一死！” 轮扁不慌不忙地说：“臣是根据臣所从事的活计而明白这个道理的。砍削轮子，榫头做得宽了则松滑而不牢固，做得太紧就必然涩滞而安不进去，臣制作的榫头松紧适宜，是因为心里怎样想的手便怎样去做。然而尽管所需要的分寸度数心里都明白，要把它用言辞表达出来却实在不可能，全靠自己手与心的配合。所以，臣无法将其中的奥秘传授给儿子，臣的儿子也无法从臣这里学到其中的奥秘。因此，臣如今七十多岁了，还只好亲手去干制作轮子的活。这样看来，古人之道的精华都已随着古人死去而无法传世，那么君王所读的，不就是古人的糟粕了吗？” 这就是著名的成语故事——轮扁斫轮，出自《庄子·天道》。庄子通过轮扁的言论，深刻地揭示了高妙之技的难以言传。 而当我们转换视角，在企业数字化转型领域，无论是软件公司还是甲方IT团队，核心上是应用级开发需求，更多的精力应该放在业务场景理解、需求把控以及业务系统实现上。但往往在一个项目进入研发之前，会花很大力气在技术架构设计、技术栈选型、通用能力对接、扩展点设计这些跟业务场景无关的技术事项上，且需要高级别的架构师来主导。大部分情况下，架构师会选开源框架来实现，慢慢沉淀为企业的研发标准体系，所以底层架构的能力往往依赖架构师个人能力。不禁发现他们与轮扁有着异曲同工之处。架构师所积累的个人经验和技术能力，往往难以通过简单的手把手教学、技术评审会完全传递给团队中的其他成员。即使有所传授，其效率也可能仅达到50%，并且随着团队成员数量的增加，这种效率还可能持续递减。因此，我们需要更多地依赖于技术手段，将架构师的经验和能力固化下来，形成一套可复制、可推广的标准技术产品。这样，每个团队成员都能够通过学习和运用这些技术，达到至少70%的传递效率，从而确保团队整体技术水平的稳步提升。这也正是开篇所强调的，企业或软件公司在工程领域所关注的特征，应当与具体研发人员的个体能力相剥离，而更多地依赖于标准化、系统化的技术手段，来确保团队整体的高效运作。 二、软件公司在工程化领域都关注哪些特征 接下来，我将从技术角度深入剖析设计初衷和技术实现原理，以展现技术公司应当“被标准化的特征”究竟长什么样。 先做个名称解释，下文中涉及“标品”、“升级”、“扩展逻辑”，这是站在软件公司角度出发描述的，如果是企业内部可以把标品理解为特定业务应用平台，升级则是业务应用平台的正常规划迭代，扩展逻辑理解为脱离平台发展的临时性需求。 1. 可逆计算 可逆计算，在应用上的特征图 场景：调查发现企业研发至少有40%的精力在跟各条业务线的团队在评审项目需求，判断需求是否合理。而且业务线对需求完善时间要求紧，每天盯着研发进度，经常问“这个需求什么时候支持，我们等着用”。导致产研部门的研发抱怨产品节奏乱，无法按照自身节奏进行迭代，被项目推着走，没有时间思考，人手不足，加班多，工作压力大…… 价值：该特性很好的规避了研发因为时间紧迫，写的一些临时代码腐蚀核心业务系统。它需要做到不论从数据模型、业务逻辑、交互展示都能有扩展能力，并且这些扩展能力与个体研发无关才行。它同时所描述的也是一个具备差量计算能力的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，使得应用的定制和恢复变得简单而高效。 技术原理：它所描述的是一个基于元数据驱动和差量计算的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，通过元数据来驱动应用的构建和变更，使得应用的定制和恢复变得简单而高效 在这种架构中，元数据起到了至关重要的作用。元数据是关于数据的数据，它描述了数据的结构、属性、关系等信息。在软件应用中，元数据可以用来描述应用的组件、功能、配置等信息。通过元数据驱动应用可以根据元数据的描述来动态地构建和配置自身的功能和结构 差量计算则是实现应用可逆性的关键。当添加或移除扩展包时，系统会根据扩展包中的元数据与标准应用的元数据进行差量计算，确定需要添加或移除的功能和组件。这种差量计算可以确保在添加扩展包后，应用能够保持原有的功能和稳定性，同时新增扩展包带来的新功能，而在去除扩展包时，应用能够恢复到原始的标准状态，不会留下任何冗余或冲突的代码和配置。 为了实现这种架构模式，元数据注册表和分布式部署能力是非常重要的。元数据注册表需要能够存储和管理大量的元数据信息，并且提供高效的查询和更新机制。分布式部署能力则能够确保应用在不同的环境中都能够稳定运行，并且能够快速地响应扩展包的添加和移除操作，即差量(扩展包》可独立存在又相互作用。 总的来说，这种基于元数据驱动和差量计算的软件架构模式为应用的定制和恢复提供了强大的支持，使得应用能够根据不同的需求进行灵活的定制和扩展。同时，它也提高了应用的可维护性和可靠性，降低了开发和维护的成本 2. 协同演进 协同演进，在应用上的特征图 场景：它所描述的场景是一个复杂的软件升级过程，其中涉及了标准应用的升级以及用户个性化扩展的保留。通过面向对象的方式扩展标准应用的功能，可以在升级过程中保持用户自定义逻辑的完整性，并同时集成新版本中的新特性。 价值：很多号称产品型的软件公司，在交付客户项目的时候，都是从标品复制一个分支，然后客户个性化直接在这个分支上改。这种模式会带来两个问题： 是当客户数量变大，每个客户的版本都不一致，维护成本很高； 是当标品升级带来的新特性无法复制给客户，导致客户满意度下降甚至流失。协同演进就是要解决这个问题。 技术原理：它需要在第一个差量计算的特性基础上才能得以完成，同时在这种升级能力中，元数据驱动和模型驱动是关键所在。元数据驱动确保了应用能够理解和处理不同版本之间的变化，包括功能的增删改以及结构的调整。模型驱动则提供了描述和管理应用结构、组件和行为的能力，它不仅能够描述模型间的关系，还能够支持面向对象的特性，如继承、重写和重载等。 具体来说，当标准应用从V1升级到V2时，元数据驱动机制会首先识别和分析两个版本之间的差异。对于用户应用1中已经扩展的A功能，由于采用了面向对象的方式进行扩展，因此在升级过程中，A+逻辑作为A功能的重写或重载版本会被保留下来。同时，V2版本中新增的B功能也会被集成到用户应用1中，因为它是作为标准应用的新特性而存在的。 这种升级能力的实现依赖于一个强大的元数据注册表和模型管理能力。元数据注册表需要能够存储和管理不同版本应用的元数据信息，包括功能、组件、结构等。模型管理能力则需要能够解析和应用这些元数据，以生成正确的应用结构和行为。同时，还需要一套高效的升级机制来确保升级过程的平滑和可靠。 总的来说，通过元数据驱动和模型驱动的结合，可以实现标准应用的平滑升级，同时保留用户个性化扩展的完整性。这种能力对于提高软件的可维护性、可扩展性和用户满意度具有重要意义 3. 公民研发和专业研发共同参与 专业研发与公民研发共同参与，在应用上的特征图 场景：它所描述是在应用开发的整个生命周期中，专业研发专注在标品的长期规划与迭代，当出现临时性的需求或者应急性的辅助场景则由非专业人士进行即公民研发方式进行。这种模式下，专业研发可以按照规划有节奏的迭代产品，做更高级的事情，不至于忙于应对临时性的事务没有深度思考，更加避免了因为临时代码堆积导致产品从内部腐化。同时利用独立的扩展逻辑包和无代码方式解决了业务的紧迫感，毕竟业务需求的合理性是很难争论出高低的。它在前两个特性基础上让研发效能进一步得到释放。 价值：它的本质是，在专业研发在以低代码的方式下实现应用，并通过无代码的方式，快速扩展逻辑功能和创建辅助性应用。整个过程无缝衔接，我们给他取个名字专业名称叫：“低无一体”。它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 技术原理：它的核心要求就是元数据在线，元数据在线能力是指能够实时地、在线地管理和操作元数据，这种能力为企业或组织带来了诸多优势。通过无 代码的方式，用户可以更加灵活地进行应用的个性化扩展，以应对各种应急性需求，从而显著提升业务的响应能力。此外，元数据在线管理还确保核心应用、核心应用扩展以及辅助应用都是基于一套统一的技术体系构建的，这为不同角色的用户（包括专业和非专业的研发人员）提供了多样化的参与方式。同时，元数据在线管理需要符合开闭原则，这确保了系统的稳定性和可扩展性，使得新的功能或需求可以通过添加新的元数据或配置来实现，而非修改现有系统。 这种低代码开发与无代码一体化的优势在于，它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 总之，从用户应用到业务实施的过程通过元数据在线得到了优化和升级。低代码开发与无代码一体化的优势使得整个过程更加高效、灵活和易于维护，为企业带来了显著的价值和竞争优势。 4. 基于平台级别的AOP能力出现反向集成 反向集成，在应用上的特征图 场景：平台级别的AOP（面向切面编程）能力允许开发者在应用程序的特定点“切入”额外的逻辑，而无需修改原有的业务代码。这种能力特别适用于横向追加平台逻辑，即在多个不同服务或功能点插入通用的处理逻辑，如日志记录、权限检查、审计、多租户、多语言等。过往在微服务架构中，这些能力都需要业务系统各自主动去对接，有了平台级别的AOP能力，则这些通用能力可以反向为所有业务系统增加特性能力，无需业务系统研发感知。这种现象我们称之为“反向集成”，能让业务研发更加专注在业务研发本身，不需要关心与业务无关的通用功能上。 价值：AOP的核心思想是将这些横切关注点（cross-cutting concerns）从业务逻辑中分离出来，使得业务代码更加清晰和专注于其核心功能。在平台级别的AOP中，标准化协议是实现这一能力的关键。平台具备统一的入口和扩展能力是非常重要的，因为它允许开发者在不修改现有代码的情况下添加新功能或修改现有功能的行为。这种能力对于快速响应业务需求变化、减少维护成本和提高代码质量都是非常有益的。 技术原理：标准化协议确保了不同组件之间的通信与语义是统一的，从而使得AOP能够更容易地实施。例如: a前后端通信要标准协议(与端无关): 这意味着无论前端是使用Web、移动应用还是其他类型的客户端，后端服务都应该能够以一种标准的方式与之通信。 bORM层要有标准协议(与数据库无关): 对象关系映射 (ORM)层应该提供一个标准的接口来与数据库进行交互，这样无论底层使用哪种数据库(如MySQL、PostgreSQL、Oracle等)，上层的业务逻辑都不需要改变。 cRPC需要标准协议(与Dubbo和Spring Cloud无关): 远程过程调用 (RPC)应该遵循一种标准协议，以便不同的服务可以无缝地进行通信，而不受特定框架 (如Dubbo、Spring Cloud等)的限制。 d所有逻辑调用统一fun调用: 这意味着平台上的所有功能调用都应该通过一个统一的入口点(如一个函数或方法)进行，这样AOP就可以在这个入口点切入额外的逻辑。 总的来说，平台级别的AOP能力通过标准化协议和统一的调用入口，为开发者提供了一种强大而灵活的方式来管理和扩展平台的逻辑功能。 5. 应用研发与部署无关 应用研发与部署无关，在应用上的特征图 场景：现在研发在选择部署方式的时候往往会选择分布式部署，或者你的客户招标需求里就写着“微服务”，构建一个微服务系统并不是一件容易的事，构建的复杂度远远超过单体系统，开发人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。另外服务与服务之间相互依赖，如果修改某一个服务，会对另一个服务产生影响，如果掌控不好。会产生不必要的麻烦。由于服务的依赖性，测试也会变得很复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试。前段时间有篇很火的文章，《从微服务转为单体架构、成本降低 90%！》，无论是选择何种部署方式，我认为这都应该跟应用研发无关。 价值：应用研发与部署无关的理念确实为现代软件架构带来了显著的优势，它使得研发团队能够专注于业务逻辑和功能实现，而无需担心具体的部署细节。这种分离带来了灵活性、效率以及成本效益的多重提升。应该采用一种同时支持分布式和单体部署、且可以自由切换的架构，我们称之为可分可合。 首先，可分可合的能力使得系统能够灵活应对业务量的变化。在业务量小的时候，可以采用单体部署的方式，简化部署流程，降低初期成本。随着业务量的增长，系统可以平滑地过渡到分布式部署，通过拆分微服务来提高系统的处理能力和扩展性。这种灵活性确保了系统既能满足未来发展的需要，又能兼顾当下的成本效益。 其次，应用级别扩容的能力使得系统性能不再受限。通过增加微服务实例或调整资源配置，系统可以按需进行扩容，从而确保在业务高峰期或突发流量下仍能保持稳定的性能。这种按需扩容的方式不仅提高了系统的可靠性，还降低了运维成本。 技术原理：核心在于逻辑调用的统一执行和智能判断。通过如funEngine这一统一调用引擎，系统能够智能地选择最适合当前业务场景和性能需求的fun调用方式。无论是同步调用、异步调用还是基于消息队列的调用方式，funEngine都能进行智能决策，确保调用的高效性和可靠性。这种统一调用的方式简化了开发过程，降低了开发难度，同时也提高了系统的可维护性和可扩展性。 此外如果作为低代码或者其他研发平台来说。被集成特性也是实现该特性的关键所在。它提供了一套标准化的接口和协议，使得其他系统或应用能够轻松地与其进行集成。这种平台框架化的特性能够作为一个统一的、可扩展的框架来支撑整个系统的运行。 综上所述，具备可分可合的能力、应用级别扩容以及逻辑调用的统一执行和被集成特性，共同构成了应用研发与部署无关这一核心特性。该特性使得软件系统能够灵活地应对业务变化，实现高效、可扩展和可维护的运行，从而满足客户的长期发展需求并兼顾当下的成本效益。

  史, 昂

  2024年5月23日

  2.3K100