1. Oinone社区Home
  2. Oinone 7天入门到精通

3.4.3.3 SPI机制-扩展点

史, 昂 • • Oinone 7天入门到精通 • 2018 views

扩展点结合拦截器的设计，oinone可以点、线、面一体化管理Function

扩展点用于扩展函数逻辑。扩展点类似于SPI机制（Service Provider Interface），是一种服务发现机制。这一机制为函数逻辑的扩展提供了可能。

一、构建第一个扩展点

自定义扩展点（举例）

在我们日常开发中，随着对业务理解的深入，往往还在一些逻辑中会预留扩展点，以便日后应对不同需求时可以灵活替换某一小块逻辑。

在3.3.4【模型的继承】一文中的PetCatItemQueryService,是独立新增函数只作公共逻辑单元。现在我们给它的实现类增加一个扩展点。在PetCatItemQueryServiceImpl的queryPage方法中原本会先查询PetCatType列表，我们这里假设这个逻辑随着业务发展未来会发生变化，我们可以预先预留【查询萌猫类型扩展点】

Step1 新增扩展点定义PetCatItemQueryCatTypeExtpoint

  1. 扩展点命名空间：在接口上用@Ext声明扩展点命名空间。会优先在本类查找@Ext，若为空则往接口向上做遍历查找，返回第一个查找到的@Ext.value注解值，使用该值再获取函数的命名空间；如果未找到，则返回扩展点全限定类名。所以我们这里扩展点命名空间为：pro.shushi.pamirs.demo.api.extpoint.PetCatItemQueryCatTypeExtpoint

  2. 扩展点技术名称：先取@ExtPoint.name，若为空则取扩展点接口方法名。所以我们这里技术名为queryCatType

package pro.shushi.pamirs.demo.api.extpoint;

import pro.shushi.pamirs.demo.api.model.PetCatType;
import pro.shushi.pamirs.meta.annotation.Ext;
import pro.shushi.pamirs.meta.annotation.ExtPoint;

import java.util.List;

@Ext
public interface PetCatItemQueryCatTypeExtpoint {

    @ExtPoint(displayName = "查询萌猫类型扩展点")
    List<PetCatType> queryCatType();

}

图3-4-3-11 新增扩展点定义PetCatItemQueryCatTypeExtpoint

Step2 修改PetCatItemQueryServiceImpl（用Ext.run模式调用）

修改queryPage，增加扩展点的使用代码。扩展点的使用有两种方式

方法一，使用命名空间和扩展点名称调用Ext.run(namespace, fun, 参数);

方法二，使用函数式接口调用Ext.run(函数式接口, 参数);

我们这里用了第二种方式

  1. 用PetCatItemQueryCatTypeExtpoint的全限定类名作为扩展点的命名空间(namespace)

  2. 用queryCatType的方法名作为扩展点的技术名称(name)

  3. 根据namespace+name去找到匹配扩展点实现，并根据规则是否匹配，以及优先级唯一确定一个扩展点实现去执行逻辑

package pro.shushi.pamirs.demo.core.service;

……省略依赖包

@Model.model(PetCatItem.MODEL_MODEL)
@Component
public class PetCatItemAction extends DataStatusBehavior<PetCatItem> {

    @Override
    protected PetCatItem fetchData(PetCatItem data) {
        return data.queryById();
    }
    @Action(displayName = "启用")
    public PetCatItem dataStatusEnable(PetCatItem data){
        data = super.dataStatusEnable(data);
        data.updateById();
        return data;
    }

    @Function.Advanced(displayName = "查询模型数据的默认过滤条件", type = FunctionTypeEnum.QUERY, managed = true)
    @Function(openLevel = {LOCAL})
    public String queryFilters() {
        StringBuilder sqlWhereCondition = new StringBuilder();
//        List<PetCatType> typeList = new PetCatType().queryList();
        List<PetCatType> typeList = Ext.run(PetCatItemQueryCatTypeExtpoint::queryCatType, new Object[]{});
        if(!CollectionUtils.isEmpty(typeList)){
//          sqlWhereCondition.append("type_id");
            sqlWhereCondition.append(PStringUtils.fieldName2Column(LambdaUtil.fetchFieldName(PetCatItem::getTypeId)));
            sqlWhereCondition.append(StringUtils.SPACE).append(SqlConstants.IN).append(CharacterConstants.LEFT_BRACKET);
            for(PetCatType petCatType: typeList){
                sqlWhereCondition.append(petCatType.getId()).append(CharacterConstants.SEPARATOR_COMMA);
            }
            sqlWhereCondition.deleteCharAt(sqlWhereCondition.lastIndexOf(CharacterConstants.SEPARATOR_COMMA));
            sqlWhereCondition.append(StringUtils.SPACE).append(CharacterConstants.RIGHT_BRACKET);
        }
        return sqlWhereCondition.toString();
    }

    ……省略其他函数
}

图3-4-3-12 修改PetCatItemQueryServiceImpl

Step3 新增扩展点实现PetCatItemQueryCatTypeExtpointOne

  1. 扩展点命名空间要与扩展点定义一致，用@Ext(PetCatItemQueryCatTypeExtpoint.class)

  2. @ExtPoint.Implement声明这是在@Ext声明的命名空间下，且技术名为queryCatType的扩展点实现

package pro.shushi.pamirs.demo.core.extpoint;

import pro.shushi.pamirs.demo.api.extpoint.PetCatItemQueryCatTypeExtpoint;
import pro.shushi.pamirs.demo.api.model.PetCatType;
import pro.shushi.pamirs.meta.annotation.Ext;
import pro.shushi.pamirs.meta.annotation.ExtPoint;
import pro.shushi.pamirs.meta.api.session.PamirsSession;

import java.util.List;

@Ext(PetCatItemQueryCatTypeExtpoint.class)
public class PetCatItemQueryCatTypeExtpointOne implements PetCatItemQueryCatTypeExtpoint {

    @Override
    @ExtPoint.Implement(displayName = "查询萌猫类型扩展点的默认实现")
    public List<PetCatType> queryCatType() {
        PamirsSession.getMessageHub().info("走的是第一个扩展点");
        List<PetCatType> typeList = new PetCatType().queryList();
        return typeList;
    }
}

图3-4-3-13 新增扩展点实现PetCatItemQueryCatTypeExtpointOne

Step4 重启看效果

  1. 萌猫商品-列表页面的逻辑没有变化正常，说明typeList从扩展点中是取到了

image.png

图3-4-3-14 示例效果

  1. 用Insomnia直接发起GraphQL请求，返回结果里可以明确知道这是扩展点实现【PetCatItemQueryCatTypeExtpointOne】执行的结果

image.png

图3-4-3-15 示例效果

Step5 自行测试扩展点的优先级

附上第二个扩展点实现的代码，快去试试吧

package pro.shushi.pamirs.demo.core.extpoint;

import pro.shushi.pamirs.demo.api.extpoint.PetCatItemQueryCatTypeExtpoint;
import pro.shushi.pamirs.demo.api.model.PetCatType;
import pro.shushi.pamirs.meta.annotation.Ext;
import pro.shushi.pamirs.meta.annotation.ExtPoint;
import pro.shushi.pamirs.meta.api.session.PamirsSession;

import java.util.List;

@Ext(PetCatItemQueryCatTypeExtpoint.class)
public class PetCatItemQueryCatTypeExtpointTwo implements PetCatItemQueryCatTypeExtpoint {

    @Override
    @ExtPoint.Implement(priority = 95,displayName = "查询萌猫类型扩展点的实现,优先级取胜")
    public List<PetCatType> queryCatType() {
        PamirsSession.getMessageHub().info("走的是第二个扩展点");
        List<PetCatType> typeList = new PetCatType().queryList();
        return typeList;
    }
}

图3-4-3-16 测试扩展点的优先级（第二个扩展点实现代码）

默认扩展点（举例）

由前端直接发起调用oinone后端Function（能被前端直接发起的Function前提是namespace挂在模型上），当前端通过GraphQL发起对函数的请求是，oinone都会默认执行三个内置扩展点分别是前置扩展点、覆盖扩展点和后置扩展点。

默认扩展点与函数的关联关系

扩展点扩展的函数与扩展点通过扩展点的命名空间和技术名称关联。扩展点与所扩展函数的命名空间一致。前置扩展点、重载扩展点和后置扩展点的技术名称的规则是所扩展函数的函数编码fun加上“Before”、“Override”和“After”后缀；方法体内调用扩展点直接使用接口调用，所以技术名称可以任意定义，只需要在同一命名空间下唯一即可。

我们在3.3.4【模型继承】一文中关于多表继承的内容有提到过通过实现扩展点来保证子模型与父模型数据同步。此次列子中我们来替换下PetShop的sayHello函数

Step1 新增扩展点定义PetShopSayhelloOverrideExtpoint

package pro.shushi.pamirs.demo.api.extpoint;

import pro.shushi.pamirs.demo.api.model.PetShop;
import pro.shushi.pamirs.meta.annotation.Ext;
import pro.shushi.pamirs.meta.annotation.ExtPoint;

@Ext(PetShop.class)
public interface PetShopSayhelloOverrideExtpoint {

    @ExtPoint(displayName = "覆盖PetShop的sayHello执行逻辑")
    public PetShop sayHelloOverride(PetShop shop);

}

图3-4-3-17 新增扩展点定义PetShopSayhelloOverrideExtpoint

Step2 新增扩展点实现PetShopSayhelloOverrideExtpointImpl

package pro.shushi.pamirs.demo.core.extpoint;

import pro.shushi.pamirs.demo.api.extpoint.PetShopSayhelloOverrideExtpoint;
import pro.shushi.pamirs.demo.api.model.PetShop;
import pro.shushi.pamirs.meta.annotation.Ext;
import pro.shushi.pamirs.meta.annotation.ExtPoint;
import pro.shushi.pamirs.meta.api.session.PamirsSession;

@Ext(PetShop.class)
public class PetShopSayhelloOverrideExtpointImpl implements PetShopSayhelloOverrideExtpoint {

    @ExtPoint.Implement(displayName = "覆盖PetShop的sayHello执行逻辑")
    public PetShop sayHelloOverride(PetShop shop){
        PamirsSession.getMessageHub().info("OverrideExtpoint Hello:"+shop.getShopName());
        return shop;
    }
}

图3-4-3-18 新增扩展点实现PetShopSayhelloOverrideExtpointImp

Step3 确保PetShop的sayHello函数存在

详见3.4.1【构建第一个Function】一文

Step4 重启查看效果

image.png

图3-4-3-19 示例效果

二、总结

oinone用默认扩展点为Function提供三种默认扩展点，并通过自定义扩展点在Function逻辑内部任意插入扩展点,让Function作为oinone的逻辑管理单元的可管理性大大提升。同时结合拦截器的设计，oinone可以点、线、面一体化管理Function

注：默认扩展点，不是由前端发起而是后端编程调用，默认不会生效，如果要生效请参考4.1.9【函数之元位指令】的一文

Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9248.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Like (0)
史, 昂's avatar史, 昂数式管理员
0 0
Previous 2024年5月23日
Next 2024年5月23日

相关推荐

  • 文件 Oinone 7天入门到精通

    文件

    文件应用下包含“导入/导出模版、导入任务、导出任务”三个菜单。其中导入/导出任务菜单比较常用。 导入/导出模版 当前版本会为租户的表格视图自动创建导出模版，此处可进行编辑、查看详情的操作。 导入任务 导入任务可以下载导入文档，点击详情可以查看该条记录的导入结果，任务信息分组中可以查看错误信息。 导出任务 和导入任务一致，导出任务菜单中可以下载导出文档，点击详情可以查看该条记录的导出结果，任务信息分组中可以查看错误信息。

    史, 昂's avatar 史, 昂
    2024年6月20日
    1.5K00
  • 第7章 Oinone的设计器们（改） Oinone 7天入门到精通

    第7章 Oinone的设计器们（改）

    史, 昂's avatar 史, 昂
    2024年5月23日
    2.8K00
  • 3.3.3 模型的数据管理器 Oinone 7天入门到精通

    3.3.3 模型的数据管理器

    数据管理器和数据构造器是Oinone为模型自动赋予的Function是内在数据管理能力，数据管理器针对存储模型是方便在大家编程模式下可以利用数据管理器Function快速达到相关数据操作的目的。数据构造器则主要用于模型进行初始化时字段默认值计算和页面交互 数据管理器 只有存储模型才有数据管理器。如果@Model.Advanced注解设置了dataManager属性为false，则表示在UI层不开放默认数据管理器。开放级别为API则表示UI层可以通过HTTP请求利用4.1.15【Pamirs标准网关协议】进行数据交互。 模型默认数据读管理器 函数编码 描述 开放级别 queryByPk 根据主键查询单条记录，会进行主键值检查 Local、Remote queryByEntity 根据实体查询单条记录 Local、Remote、Api queryByWrapper 根据查询类查询单条记录 Local、Remote queryListByEntity 根据实体查询返回记录列表 Local、Remote queryListByWrapper 根据查询类查询记录列表 Local、Remote queryListByPage 根据实体分页查询返回记录列表 Local、Remote queryListByPageAndWrapper 根据查询类分页查询记录列表 Local、Remote queryPage 分页查询返回分页对象，分页对象中包含记录列表 Local、Remote、Api countByEntity 按实体条件获取记录数量 Local、Remote countByWrapper 按查询类条件获取记录数量 Local、Remote 表3-3-3-1 模型默认数据读管理器 模型默认数据写管理器 函数编码 描述 开放级别 createOne 提交新增单条记录 Local、Remote createOrUpdate 新增或更新，需要为模型设置唯一索引，如果数据库检测到索引冲突，会更新数据，若未冲突则新增数据 Local、Remote updateByPk 根据主键更新单条记录，会进行主键值检查 Local、Remote updateByUniqueField 条件更新，条件中必须包含唯一索引字段 Local、Remote updateByEntity 按实体条件更新记录 Local、Remote、Api updateByWrapper 按查询类条件更新记录 Local、Remote createBatch 批量新增记录 Local、Remote createOrUpdateBatch 批量新增或更新记录 Local、Remote updateBatch 根据主键批量更新记录，会进行主键值检查 Local、Remote deleteByPk 根据主键删除单条记录，会进行主键值检查 Local、Remote deleteByPks 根据主键批量删除，会进行主键值检查 Local、Remote deleteByUniqueField 按条件删除记录，条件中必须包含唯一索引字段 Local、Remote deleteByEntity 根据实体条件删除 Local、Remote、Api deleteByWrapper 根据查询类条件删除 Local、Remote createWithField 新增实体记录并更新实体字段记录 Local、Remote、Api updateWithField 更新实体记录并更新实体字段记录 Local、Remote、Api deleteWithFieldBatch 批量删除实体记录并删除关联关系 Local、Remote、Api 表3-3-3-2 模型默认数据写管理器 如果模型继承IdModel，模型会自动设置主键设置为id，则会继承queryById、updateById和deleteById函数。 queryById（详情，根据ID查询单条记录，开放级别为Remote） updateById（提交更新单条记录，根据ID更新单条记录，开放级别为Remote） deleteById（提交删除单条记录，根据ID删除单条记录，开放级别为Remote） 如果模型继承CodeModel，模型也会继承IdModel的数据管理器，编码字段code为唯一索引字段。在新增数据时会根据编码生成规则自动设置编码字段code的值，继承queryByCode、updateByCode和deleteByCode函数。 queryByCode（详情，根据code查询单条记录，开放级别为Remote） updateByCode（提交更新单条记录，根据code更新单条记录，开放级别为Remote） deleteByCode（提交删除单条记录，根据code删除单条记录，开放级别为Remote） 没有主键或唯一索引的模型，在UI层不会开放默认数据写管理器。 #### 使用场景 图3-3-3-1 数据管理器使用场景 数据构造器 模型数据构造器 construct：供前端新开页面构造默认数据使用。所有模型都拥有construct构造器，默认会将字段上配置的默认值返回给前端，另外可以在子类中覆盖construct方法。数据构造器 construct函数的开放级别为API，函数类型为QUERY查询函数，系统将识别模型中的以construct命名的函数强制设置为API开放级别和QUERY查询类型。 可以使用@Field的defaultValue属性配置字段的默认值。注意，枚举的默认值为枚举的name。

    史, 昂's avatar 史, 昂
    2024年5月23日
    2.6K10
  • 1.3 Oinone的生态思考 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 企业数字化转型核心领域

    史, 昂's avatar 史, 昂
    2024年5月23日
    2.7K00

  • 产品白皮书

    史, 昂's avatar 史, 昂
    Oinone 7天入门到精通 2023年5月23日
    1.4K00

Leave a Reply

Please Login to Comment