Wen/Wen Jing
Editor/Mai Biyu
preface
In the software architecture design, there is a classic three-layer structure, namely: the presentation layer, the business logic layer and the data access layer.
- Presentation Layer (UIL): The interface presented to the user, that is, what the user sees when using the system.
- Business Logic Layer (BLL): The operation of a specific problem, or the operation of the data layer, the processing of data business logic.
- Data Access Layer (DAL): Add, delete, modify, find, etc. for data.
In the application construction process of Mingdao Cloud, although developers are not required to strictly define the three-layer structure, the concept of layering can still be experienced in many product designs. For example, on the "front-end form" that displays the record information, we can call a "background workflow" by adding, deleting, modifying, or customizing the data. A variety of complex logic can be processed in the workflow and data manipulation can be performed on the corresponding "underlying worksheets".
Such design ideas are easy for users to understand, whether it is a programmer or a novice who is accustomed to code development, as long as they are slightly familiar with the basic functional components of each layer, they can easily design a variety of complex and personalized business applications.
The design of the three-layer structure is highly extensible, which can well reduce the coupling degree between the layers, which is conducive to standardization and logical reuse. But it can also bring some problems, such as:
- Reduced system performance to a certain extent. For example, Mingdao Cloud's batch complex processing of data mainly relies on a large number of workflows (including sub-processes), and when the complex workflows are nested more, it will be difficult to maintain.
- The front and rear end are associated with the processing, and the whole body is involved. For example, in order to display a comprehensive data visualization on the front-end large screen, a combination of fields, data associations, and workflows can be achieved.
Today we're going to explore a special way to break down the "front-end" barrier and let us build a custom cache at the front of the worksheet. In some special scenarios, you can improve data performance and make the application design more concise.
Customize the data structure to turn text controls into caches
Starting from version 7.3, Mingdao Cloud products have taken a step forward on the basis of the original function default values and began to support "custom functions". Such a small iteration can open a door for us in front-end and back-end development, allowing us to try new ways to solve the problem of complex data interaction between front-end and back-end.
At the heart of this idea is to use the worksheet text control as a front-end data storage container, reading and front-end logic processing through custom functions. The data itself is still derived from a regular worksheet, but workflows can read data from one or more tables and refactor a separate front-end data source. This data can be stored directly in the worksheet as a "data cache" accessible to front-end custom functions.
Example effect
Below, I'll use a simple example to demonstrate this process. Example background: Enter an Employee Number in a worksheet and the system can automatically bring out the employee's name, position, and entry date.
The general steps to achieve this effect are:
- Create a single personnel position association control in the query table;
- Sets a default value for this associated control to query other tables, based on the currently entered work number
- Introduce the associated related field to the current record through the default value of the other table field or text control.
As you can see, this process requires the joint use of multiple components and must require the query form to dynamically establish an association with the people table. Foreground execution is slower, and the associated fields cannot be refreshed in real time. And through the custom function pattern introduced today can be perfectly solved these problems, let's take a look at the effect.
Step by step
1. First, set up a "data cache" container in the query form, using ordinary text controls; can be left hidden.
2. According to the actual business demand for data, use the workflow to generate a specific JSON format data source in the background and save it in the "Data Cache" container above. The data source format here is very flexible and can support some relatively complex business (reference: Convert worksheet data into arrays using code blocks https://bbs.mingdao.net/topic/137).
3. Set the custom function in the target control. By loading the corresponding "cache data" and combining it with the custom JS code, you can realize the custom judgment and calculation logic. As in this example, an array object is retrieved based on the work number entered and the field values in it are displayed (the data can be refreshed in real time based on the input).
More application scenarios
In addition to entering the work number to automatically display employee information, this operation method can also be applied in various scenarios:
1. Realize the one-time loading of test paper questions in the examination assessment
In the online examination and assessment scenario, the test paper questions are loaded at one time; The switching of topics does not require background workflow, and the pure front-end refresh is smoother.
2. The order details are dynamically summarized according to the conditions
In the standard way, we can only preset a few summary controls with filters and then add up all the summary values with formula fields. With this custom function, you can achieve dynamic summarization by condition. The number of controls is also used less, and the number of summaries can easily break the limit of 1000 bars.
The data statistics are implemented as follows:
3. More complex judgments
In the scenario where a meeting room is scheduled, a list of available rooms is automatically determined and displayed based on a custom meeting start and end time.
summary
The approach discussed today allows us to build our own independent front-end data cache outside of the standard product system, and implement some special data processing logic based on custom functions. Of course, this method also has certain limitations and requirements:
1. Triggered only when data operations are performed manually
A custom function is a pure "front-end" feature that can only be triggered when data manipulation is performed manually. If other events affect changes to the data, it is still handled based on a standard "background" workflow.
2. It cannot be synchronized with the underlying worksheet data in real time
Although the aggregate calculation of a large amount of data can exceed 1000, because this data source is only a copy of the underlying worksheet, it cannot be synchronized with the underlying worksheet data in real time unless it is frequently synchronized through workflows. So this approach is suitable for handling relatively static data. As in the example above, after a set of test questions is generated, it will generally not change again, and the details of an order will not be changed after entering a certain stage, such as approval.
After reading this article, you may wish to try to integrate front-end and back-end data in this way and do some interesting exploration.