1.5 Oinone与行业对比

相关推荐

• Oinone 7天入门到精通

  2.4.2 Oinone独特性之每一个需求都可以是一个模块

  我们的Oinone平台采用模型驱动的方式，并符合面向对象设计原则，每个需求都可以是一个独立模块，可以独立安装、升级和卸载。这让系统真正像乐高积木一样搭建，具有高度的灵活性和可维护性。 与大部分低代码或无代码平台不同的是，它们的应用市场上的应用往往是模板式的，也就是说，这是一个拷贝，个性化只能在应用上直接修改，而且一旦修改就不能升级。这对于软件公司和客户来说都非常痛苦。客户无法享受到软件公司产品的升级功能，而软件公司在服务大量客户时，也会面临不同版本的维护问题，成本也非常高。而我们的Oinone平台完全避免了这些问题，让客户和软件公司都可以从中受益（如下图2-9、2-10所示）。 图2-9软件公司与客户项目的关系-让标准与个性化共存 图2-10 软件公司与客户项目的关系-让升级无忧 实现原理 在满足客户个性化定制需求时，传统的方法通常是直接修改标准产品源码，但这样做会带来一个问题：标准产品无法持续升级。相反，无论是在OP模式还是SaaS模式下，Oinone都采用全新的模块为客户进行个性化开发，保持标准产品和个性化模块的独立维护和升级。这是因为在元数据设计时，Oinone采用了面向对象的设计原则，实现了元数据设计与面向对象设计思想的完美融合。 面向对象设计的核心特征包括封装、继承、多态，而Oinone的元数据设计完全融入了这些思想。下面是几个例子，说明Oinone的元数据设计如何体现面向对象设计的核心特征，并带来了什么好处： 继承：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来扩展模型的字段、逻辑、展示。 多态：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来覆盖模型的原有字段、逻辑、展示。 封装：外部无需关心模型内部如何实现，只需按照不同场景调用模型对应开放级别的字段、逻辑、展示。 这些特征和优势使得Oinone在满足客户个性化需求时更加灵活和可持续，同时使得标准产品的维护和升级变得更加容易和高效。 在Java语言设计中，万物皆对象，一切都以对象为基础。而Oinone的元数据设计则是以模型为出发点，作为数据和行为的承载体。如下图2-11清晰地描述了Java面向对象编程中封装、继承、多态在Oinone元数据中的对应关系。Oinone元数据描述了B对象继承A对象并拥有其所有属性和方法，并覆盖了A对象的属性1和方法1，同时新增了属性3和方法3。 此外，Oinone的面向对象特性是用元数据来描述的。一方面，我们基于Java编码规范收集相关元数据，以保持不改变Java编程习惯。另一方面，方法和对象的挂载是松耦合的，只要按照元数据规范进行挂载，就能轻松地将其附加到模型上。在不改变原有A对象的情况下，我们可以直接增加方法和属性（如下图2-12所示）。 图2-11 java面向对象在Oinone元数据中对应 图2-12 java对象的修改 VS Oinone元数据模型的修改 Oinone函数不仅支持面向对象的继承和多态特性，还提供了面向切面的拦截器和SPI机制的扩展点，以应对方法逻辑的覆盖和扩展，以及系统层面的逻辑扩展（如下图2-13所示）。这些扩展功能可以独立地在模块中维护。 其中，拦截器可以在不侵入函数逻辑的情况下，根据优先级为满足条件的函数添加执行前和执行后的逻辑。 扩展点是一种类似于SPI机制的逻辑扩展机制，用于扩展函数的逻辑。通过这一机制，可以对函数逻辑进行灵活的扩展，以满足不同的业务需求。 图2-13 Oinone函数拦截与扩展机制 不管是对象、属性还是方法，都可以以独立的模块方式来扩展，这就使得每一个需求都可以成为一个独立的模块，方便我们在研发标准产品时进行模块化的划分，同时也让我们在以低代码模式为客户进行二次开发时，能够更好地支持“标准产品迭代与个性化保持独立”的需求。在2.4.3【oinone独特性之低无一体】一文中，我们也提到了这个特性，但那是在低无一体的情况下，通过元数据融合来实现的。让我们看看基于低代码开发模式下，典型的Oinone二次开发工程结构（如下图2-14所示），就可以更好地理解这个特性啦！ 图2-14 Oinone典型的二开工程结构

  史, 昂

  2024年5月23日

  1.6K000
• Oinone 7天入门到精通

  4.1.20 框架之Session

  在日常开发中，我们经常需要把一些通用的信息放入程序执行的上下文中，以便业务开发人员快速获取。那么oinone的PamirsSession就是来解决此类问题的。 一、PamirsSession介绍 在oinone的体系中PamirsSession是执行上下文的承载，您能从中获取业务基础信息、指令信息、元数据信息、环境信息、请求参数，以及前后端MessageHub等。在前面的学习过程中我们已经多次接触到了如何使用PamirsSession： 在4.1.19【框架之网关协议-后端占位符】一文中，使用PamirsSession.getUserId()来获取当前登入用户Id，诸如此类的业务基础信息； 在4.1.18【框架之网关协议-variables变量】一文中，使用PamirsSession.getRequestVariables()得到PamirsRequestVariables对象，进而获取前端请求的相关信息； 在4.1.5【模型之持久层配置】一文中，使用PamirsSession.directive(),来操作元位指令系统，进而影响执行策略； 在4.1.13【Action之校验】、3.4.1【构建第一个Function】等文章中，都用到PamirsSession.getMessageHub()来设置返回消息。 二、构建模块自身Session（举例） 不同的应用场景对PamirsSession的诉求是不一样的，这个时候我们就可以去扩展PamirsSession来达到我们的目的 构建模块自身Session的步骤 构建自身特有的数据结构XSessionData 对XSessionData进行线程级缓存封装 利用Hook机制初始化XSessionData并放到ThreadLocal中 定义自身XSessionApi 实现XSessionApi接口、SessionClearApi。在请求结束时会调用SessionClearApi的clear方法 定义XSession继承PamirsSession 扩展PamirsSession的经典案例设计图 图4-1-20-1 扩展PamirsSession的经典案例设计图 构建Demo应用自身Session 下面的例子为给Session放入当前登陆用户 Step1 新建DemoSessionData类 构建自身特有的数据结构DemoSessionData，增加一个模型为PamirsUser的字段user，DemoSessionData用Data注解，注意要用Oinone平台提供的@Data package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.annotation.fun.Data; import pro.shushi.pamirs.user.api.model.PamirsUser; @Data public class DemoSessionData { private PamirsUser user; } 图4-1-20-2 新建DemoSessionData类 Step2 新建DemoSessionCache 对DemoSessionData进行线程级缓存封装 package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.api.CommonApiFactory; import pro.shushi.pamirs.meta.api.session.PamirsSession; import pro.shushi.pamirs.user.api.model.PamirsUser; import pro.shushi.pamirs.user.api.service.UserService; public class DemoSessionCache { private static final ThreadLocal<DemoSessionData> BIZ_DATA_THREAD_LOCAL = new ThreadLocal<>(); public static PamirsUser getUser(){ return BIZ_DATA_THREAD_LOCAL.get()==null?null:BIZ_DATA_THREAD_LOCAL.get().getUser(); } public static void init(){ if(getUser()!=null){ return ; } Long uid = PamirsSession.getUserId(); if(uid == null){ return; } PamirsUser user = CommonApiFactory.getApi(UserService.class).queryById(uid); if(user!=null){ DemoSessionData demoSessionData = new DemoSessionData(); demoSessionData.setUser(user); BIZ_DATA_THREAD_LOCAL.set(demoSessionData); } } public static void clear(){ BIZ_DATA_THREAD_LOCAL.remove(); } } 图4-1-20-3 对DemoSessionData进行线程级缓存封装 Step3 新建DemoSessionHook 利用Hook机制，调用DemoSessionCache的init方法初始化DemoSessionData并放到ThreadLocal中。 @Hook(module= DemoModule.MODULE_MODULE), 规定只有增对DemoModule模块访问的请求该拦截器才会生效，不然其他模块的请求都会被DemoSessionHook拦截。 package pro.shushi.pamirs.demo.core.hook; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.DemoModule; import pro.shushi.pamirs.demo.core.session.DemoSessionCache; import pro.shushi.pamirs.meta.annotation.Hook; import pro.shushi.pamirs.meta.api.core.faas.HookBefore; import pro.shushi.pamirs.meta.api.dto.fun.Function; @Component public class DemoSessionHook implements HookBefore { @Override @Hook(priority = 1,module = DemoModule.MODULE_MODULE) public Object run(Function function, Object… args) { DemoSessionCache.init(); return function; } } 图4-1-20-4 新建DemoSessionHook Step4 新建DemoSessionApi package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.api.CommonApi; import pro.shushi.pamirs.user.api.model.PamirsUser; public interface DemoSessionApi extends CommonApi { PamirsUser getUser(); } 图4-1-20-5 新建DemoSessionApi Step5…

  史, 昂

  2024年5月23日

  1.9K000
• Oinone 7天入门到精通

  1.3 Oinone的生态思考

  以“企业级软件生态”的方式去帮助企业建立“一站式的商业智能软件”。 通过观察信息化到数字化的软件行业发展历程（如下图1-3所示），我们可以发现，企业真正需要的是一站式的软件产品。然而，一站式的软件产品往往都是从单个领域的需求满足开始，这在信息化时代和数字化时代都是如此。在信息化时代，以ERP为终点的一站式趋势逐渐形成；而在数字化时代，中台概念的提出则标志着一站式的趋势重新开始。本文将从企业数字化转型所面临的困境出发，探讨Oinone的生态思考。 图1-3 从信息化到数字化软件行业发展历程 1.3.1 与中台的渊源 中台概念的提出标志着企业数字化改造进入了一个新的时代。随着数字化转型不断深入，企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下，“敏捷响应，低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。需要澄清的是，互联网中台架构只是一种企业解决数据割裂、系统隔离，建立一站式商业智能软件的技术概念之一，并不是技术标准。而且这种方式只适用于企业自建模式。在多供应商环境下，则会适得其反，导致建立更复杂的烟囱系统。 阿里于15年提出中台架构概念，抓住了企业数字化转型的核心诉求，即“敏捷响应，低成本快速创新”。然而，阿里作为一家生态公司，在16年时基本上是带着合作伙伴来给企业交付，但由于伙伴对互联网技术的理解和能力的限制，基本上都做得不好，甚至失败。在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题： 不是说敏捷响应吗？为什么改个需求这么慢，不但时间更长，付出的成本也更高了？是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们，更不用说是手动挡的。 不是说能力中心吗？当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了？是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢？新项目的供应商还是客户自己？ 不是说性能好吗？为什么我投入的物理资源更多了？是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。 1.3.2 找解决方案 在考虑解决方案之前，我们需要思考企业数字化软件的最终状态将是什么样子。目前有两种主要的方案（如下图1-4所示）： 第一种是以自建研发团队为核心。中国的大型企业已经开始尝试这种模式，看起来似乎是一个时下比较流行的可行性方案。然而，绝大多数企业由于成本、人才团队等原因而难以坚持下去，只能与供应商合作开发。 第二种是以供应商为核心。由于大多数企业无法选择第一种路径，他们必须接受目前分散的情况，并通过系统集成尽可能拉通各个系统。尽管如此，在数字化时代中，真正意义上的一站式商业智能软件供应商还未出现。 图1-4 企业数字化桎梏和囹圄 对企业来说，这两种方案都非常艰难，但在大规模数字化历程中又不得不做出选择。此外，我们还能清晰看到以下几点： "敏捷响应，低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求 目前没有一家软件供应商能满足企业所有外围商业场景，也不可能有这样的供应商 绝大部分企业需要软件供应商，而不是自建 如何突破这种局面也成为中国软件行业发展的一个机遇。因此，我的思考是： 我们的目标不是依托于提升研发人员的能力，而是降低互联网架构的门槛，让更多企业真正拥有“敏捷响应，低成本快速创新”的能力。 我们的目标不是输出中台方法论，而是提供中台建设的技术平台。 我们的目标不是只服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。 今天，许多中台软件公司告诉企业：“中台是持续演进和快速迭代的过程，因此企业需要组建中台架构团队来实现，而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的，因为我们之前提到企业需要具备敏捷响应业务的能力，即应变能力，因为应变是不断变化的。然而，后半部分是不正确的，因为今天的企业已经有能力组建团队，那么这些中台软件公司到底有什么用呢？企业真的缺少方法论吗？在19年，我就提出了自己的看法：没有低代码能力的中台公司都在收取智商税，都在欺诈，因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗？这些流氓公司赚了很多钱，最后责怪企业无法招到人才，这是企业的责任。因此，仍然认为“最好的赋能是降低门槛，而不是让客户提高技术水平”。 最终，我们得出了一个服务模式的想法：构建企业级的软件生态。企业级软件生态的确切定义是：通过开放的方式，让企业本身以及不同的软件供应商共同参与，遵循相同的技术和数据规范，打造一体化、无需集成的各类企业级软件。如果要打造企业级软件生态，我们列出了六个要点（如下图1-5所示）。 图1-5 打造企业级软件生态需要具备的六大能力 我很幸运地有机会通过“企业级软件生态”的方式，为企业建立“一站式的商业支持平台”提供帮助。我们的Oinone平台结合了低代码开发、通用数据模型和业务产品的优势（如下图1-6所示）。 图1-6 Oinone = 低代码开发平台 + 通用数据模型 + 业务产品 我们对Oinone一站式低代码商业支撑平台展开介绍，它大致分为4部分： 以低代码开发平台为基础，输出具备互联网架构下的软件快速开发标准。这可以帮助企业快速构建符合互联网架构标准的应用程序，从而实现快速响应和低成本创新。 以通用数据模型为基础，满足不同软件基于同一套数据标准的扩展能力。这可以确保不同软件系统之间的数据兼容性和互操作性，避免数据孤岛和信息隔离。 在业务产品层面上，企业和伙伴基于相同的技术标准和数据标准共同提供解决方案。这可以帮助企业和伙伴共同开发出符合标准的商业支撑平台，以提高业务效率和创新能力。 最后是无代码设计器，用于满足项目开展中，超出业务标品范围之外的需求，或者针对标品的临时需求。这可以帮助业务人员在不需要专业软件支持的情况下，自主解决业务需求，并支持部门间的协同工作。 1.3.3 生态建设 Oinone致力于打造全球最大的无需集成的商业应用程序及其生态系统，通过开源内核、汇集数千名开发人员和业务专家，为企业提供成本效益、一体化、模块化的解决方案，解决所有商业需求，让不同技术之间的合作变得简单易行，摆脱烦恼的集成问题。 在客户和场景领域，我们严格限定了自身的专注领域。针对超大型头部企业，我们专注于树立标杆，而对于大、中、小型企业，则交由我们的伙伴来支持。小微企业可以通过我们的开源社区版获得覆盖。在企业数字化转型的核心领域中，我们的解决方案涵盖了数字化交易场景、全渠道订单履约场景、数字化采购场景、数字化营销等产品。在其他领域，我们完全交由伙伴来建设。由于我们自身在企业协同商务领域拥有深厚的背景，因此在该领域提供的产品拥有特别的优势。 企业数字化转型核心领域 图1-7 企业数字化转型核心领域

  史, 昂

  2024年5月23日

  2.5K000

• 4.5 研发辅助

  这里都是一些提升研发效率的小工具

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.6K000
• Oinone 7天入门到精通

  4.1.5 模型之持久层配置

  一、批量操作 批量操作包括批量创建与批量更新。批量操作的提交类型系统默认值为batchCommit。 批量提交类型： useAffectRows，循环单次单条脚本提交，返回实际影响行数 useAndJudgeAffectRows，循环单次单条脚本提交，返回实际影响行数，若实际影响行数与输入不一致，抛出异常 collectionCommit，将多个单条更新脚本拼接成一个脚本提交，不能返回实际影响行数 batchCommit，使用单条更新脚本批量提交，不能返回实际影响行数。 全局配置 pamirs: mapper: batch: batchCommit 图4-1-5-1 全局配置 运行时配置 非乐观锁模型系统默认采用batchCommit提交更新操作；乐观锁模型默认采用useAndJudgeAffectRows提交更新操作。也可以使用以下方式在运行时改变批量提交方式。 Spider.getDefaultExtension(BatchApi.class).run(() -> { 更新逻辑 }, 批量提交类型枚举); 图4-1-5-2 运行时配置 运行时校正 如果模型配置了数据库自增主键，而批量新增的批量提交类型为batchCommit，则系统将批量提交类型变更为collectionCommit（如果使用batchCommit，则需要单条提交以获得正确的主键返回值，性能有所损失）。 如果模型配置了乐观锁，而批量更新的批量提交类型为collectionCommit或者batchCommit，则系统将批量提交类型变更为useAndJudgeAffectRows。也可以失效乐观锁，让系统不做批量提交类型变更处理。 二、乐观锁（举例） 在一些会碰到并发修改的数据，往往需要进行并发控制，一般数据库层面有两种一种是悲观锁、一种是乐观锁。oinone对乐观锁进行了良好支持 定义方式 乐观锁的两种定义方式： 通过快捷继承VersionModel，构建带有乐观锁，唯一编码code且主键为id的模型。 可以在字段上使用@Field.Version注解来标识该模型更新数据时使用乐观锁 如果更新的实际影响行数与入参数量不一致，则会抛出异常，错误码为10150024。如果是批量更新数据，为了返回准确的实际影响行数，批量更新由批量提交改为循环单条数据提交更新，性能有所损失。 失效乐观锁 一个模型在某些场景下需要使用乐观锁来更新数据，而另一些场景不需要使用乐观锁来更新数据，则可以使用以下方式在一些场景下失效乐观锁。更多元位指令用法详见4.1.9【函数之元位指令】一文。 PamirsSession.directive().disableOptimisticLocker(); try{ 更新逻辑 } finally { PamirsSession.directive().enableOptimisticLocker(); } 图4-1-5-3 失效乐观锁 不抛乐观锁异常 将批量提交类型设置为useAffectRows即可，这样可改由外层逻辑对返回的实际影响行数进行自主判断。 Spider.getDefaultExtension(BatchApi.class).run(() -> { 更新逻辑，返回实际影响行数 }, BatchCommitTypeEnum.useAffectRows); 图4-1-5-4 将批量提交类型设置为useAffectRows 构建第一个VersionModel Step1 新建PetItemInventroy模型，继承快捷模型VersionModel package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.base.common.VersionModel; import java.math.BigDecimal; @Model.model(PetItemInventroy.MODEL_MODEL) @Model(displayName = "宠物商品库存",summary="宠物商品库存",labelFields = {"itemName"}) public class PetItemInventroy extends VersionModel { public static final String MODEL_MODEL="demo.PetItemInventroy"; @Field(displayName = "商品名称") private String itemName; @Field(displayName = "库存数量") private BigDecimal quantity; } 图4-1-5-5 新建PetItemInventroy模型 Step2 修改DemoMenu，增加访问入口 @UxMenu("商品库存")@UxRoute(PetItemInventroy.MODEL_MODEL) class PetItemInventroyMenu{} 图4-1-5-6 修改DemoMenu Step3 重启看效果 体验一：页面上新增、修改数据库字段中的opt_version会自动加一 图4-1-5-7 示例效果一 图4-1-5-8 示例效果二 图4-1-5-9 示例效果三 图4-1-5-10 示例效果四 体验二：同时打两个页面，依次点击，您会发现一个改成功，一个没有改成功。但页面都没有报错，只是update返回影响行数一个为1，另一个为0而已。 图4-1-5-11 编辑宠物商品库存 图4-1-5-12 宠物商品库存列表 注：增加了乐观锁，我们在写代码的时候一定要注意，单记录更新操作的时候要去判断返回结果（影响行数），不然没改成功，程序是不会抛错的。不像batch接口默认会报错 Step4 预留任务：重写PetItemInventroy的update函数 留个任务，请各位小伙伴自行测试玩玩，这样会更有体感 package pro.shushi.pamirs.demo.core.action; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.enumeration.DemoExpEnumerate; import pro.shushi.pamirs.demo.api.model.PetItemInventroy; import pro.shushi.pamirs.demo.api.model.PetTalent; import pro.shushi.pamirs.meta.annotation.Function; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.common.exception.PamirsException; import pro.shushi.pamirs.meta.constant.FunctionConstants; import pro.shushi.pamirs.meta.enmu.FunctionOpenEnum; import pro.shushi.pamirs.meta.enmu.FunctionTypeEnum; import java.util.ArrayList; import java.util.List; @Model.model(PetItemInventroy.MODEL_MODEL) @Component public class PetItemInventroyAction { @Function.Advanced(type= FunctionTypeEnum.UPDATE) @Function.fun(FunctionConstants.update) @Function(openLevel = {FunctionOpenEnum.API}) public PetItemInventroy update(PetItemInventroy data){ List<PetItemInventroy> inventroys = new ArrayList<>(); inventroys.add(data); //批量更新会，自动抛错 int i =…

  史, 昂

  2024年5月23日

  1.7K000