巧用自定义函数，文本控件秒变高速缓存

文/文静编辑/麦壁瑜

前言

在软件体系架构设计中，有一种最经典的三层结构，即：表现层、业务逻辑层和数据访问层。

• 表现层（UIL）：展现给用户的界面，即用户在使用系统时他的所见所得。

• 业务逻辑层（BLL)：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

• 数据访问层（DAL)：针对数据的增添、删除、修改、查找等。

在明道云的应用搭建过程中，虽然不要求开发者去严格定义三层结构，但在很多产品设计上仍然可以体会到分层的理念。例如：在显示记录信息的“前端表单”上，我们可以通过数据的增删改或是自定义按钮来调用一个“后台工作流”。工作流中可以进行各种复杂逻辑的处理，并对相应的“底层工作表”进行数据操作。

这样的设计思路易于用户理解，不管是习惯代码开发的程序员还是新手小白，只要稍加熟悉各层基本功能组件，就能很容易设计各种复杂和个性化的业务应用。

三层结构的设计扩展性强，可以很好地降低各层之间的耦合度，有利于标准化和逻辑的复用。但是它也会带来一些问题，如：

• 一定程度上降低了系统性能。例如：明道云对数据的批量复杂处理主要依靠大量的工作流（包含子流程），当复杂的工作流嵌套较多的时候，维护起来会有难度。

• 前后端关联处理，牵一发而动全身。例如：为了在前端大屏上显示全面的数据可视化效果，要组合运用一系列字段、数据关联、工作流才可以实现。

今天就探讨一种特殊的方法，打破“前后端”的藩篱，让我们能在工作表前端建立一个自定义的高速缓存。在一些特殊场景下可以提升数据性能，同时让应用设计更加简洁。

自定义数据结构，把文本控件变成高速缓存

从 7.3 版本开始，明道云产品在原有的函数默认值基础上又往前推动了一步，开始支持“自定义函数”。这样一个小迭代，却能为我们在前后端开发上开启一扇大门，让我们可以尝试用新的方式来解决前后端复杂数据交互的问题。

这个思路的核心是将工作表文本控件作为前端数据存储容器，通过自定义函数进行读取和前端逻辑处理。其中，数据本身还是来源于常规的工作表，但是可以通过工作流读取一个或多个表的数据，并重构出一个独立的前端数据源。这个数据可以直接存储在工作表中，作为前端自定义函数可访问的“数据缓存”。

示例效果

下面，我先用一个简单示例来演示这个操作过程。示例背景：在一个工作表中输入“员工工号”，系统就可以自动带出该员工的姓名、岗位、入职日期。

实现这个效果的常规方式步骤为：

• 在查询表中建立一个单条的人员岗位关联控件；

• 为这个关联控件设置一个查询他表的默认值，条件为当前输入的工号

• 通过他表字段或者文本控件默认值把该关联的相关字段引入到当前记录。

可以看出，这个过程需要多个组件的联合使用，且必须要求查询表单动态建立和人员表的关联。前台执行效率较慢，关联字段也做不到实时刷新显示。而通过今天介绍的自定义函数模式就可以完美解决这些问题，下面看一下效果。

步骤讲解

1.首先，在查询表单中设置一个“数据缓存”容器，用普通的文本控件即可；可保持隐藏状态。

2.根据实际业务对数据的需求，用工作流在后台生成特定 JSON 格式的数据源，并保存在上面的“数据缓存”容器中。这里的数据源格式非常灵活，可以支持一些相对复杂的业务（参考：运用代码块将工作表数据转为数组 https://bbs.mingdao.net/topic/137）。

3.在目标控件中设置自定义函数。通过加载对应的“缓存数据”，再结合自定义 JS 代码，即可实现自定义的判断和计算逻辑。如本示例中，根据输入的工号检索数组对象，并显示其中的字段值（可以根据输入实时刷新数据）。

更多应用场景

除了输入工号自动显示员工信息以外，这个操作方法还可以应用在各种场景中：

1.考试测评中实现试卷题目一次性加载

在线考试、测评场景中，试卷题目一次性加载；题目的切换无需后台工作流，纯前端刷新更加顺畅。

2.订单明细按条件动态汇总统计

如果按标准的方式，我们只能先预置几个带有筛选条件的汇总控件，再用公式字段将所有汇总值加起来。而用这种自定义函数就可以实现按条件动态汇总。控件的使用数量也更少，而且汇总数量可以轻松突破 1000 条的限制。

数据统计实现方式如下：

3.较为复杂的判断

在预定会议室的场景中，要按照自定义的会议起止时间，自动判断并显示可用会议室列表。

总结

今天探讨的这种方式让我们在标准产品体系之外，可以构建出自己独立的前端数据缓存，实现基于自定义函数的一些特殊数据处理逻辑。当然，这种方式也有一定的局限和要求：

1.只在人工执行数据操作时触发

自定义函数是一个纯“前端”功能，只能在人工进行数据操作的时候才会触发。如果其他事件会影响数据的变更还是要基于标准的“后台”工作流来处理。

2.本身无法和底层工作表数据实时同步

虽然对大量数据的汇总计算可以超过 1000 条，但是由于此数据源只是底层工作表的一个副本，本身无法和底层工作表数据进行实时同步，除非通过工作流频繁同步。所以这种方式适合处理相对静态的数据。如上面的示例，一套考题生成后一般就不会再变化了，一个订单的明细在进入一定阶段后，如审批通过，也不会再做变更。

看完这篇文章的你，不妨也尝试用这种方式整合前后端数据，做一些有趣的探索。