A set of general interface platforms has been open sourced before, see the column https://blog.csdn.net/seawaving/category_11610162.html for details .
Now, the general interface platform is integrated into the new application development platform as a module, and the general interface platform uniformly exposes the API data interface of the application system and pushes event messages.
original structure
The previous common interface platform is mainly composed of two modules, one is platform-cip (cip is the abbreviation of common interface platform), which is the main body of the interface platform, and the other is platform-cip-common, which is dependent on platform-cip.
The reason why platform-cip-common needs to be independent is because of the message service based on netty, platform-cip is equivalent to the server of the message, and there is a relatively independent client. Some classes of the server and the client need to be shared, so extract Come out as a public module.
Architecture optimization
In fact, the main body of the interface platform, platform-cip, contains three pieces of content:
1. Provide API data interface to the outside world
2. Web socket server based on netty
3. Maintenance of basic data of the platform itself, such as application and API service list , list of messaging services, subscriptions, etc.
This integration is not a simple migration, but includes refactoring and optimization, and further splits platform-cip into three modules.
Integration work
1. Create a module
The first step is to create 4 modules, all prefixed with platform-cip platform
-cip-common: public foundation
platform-cip-api: API service
platform-cip-message: message service
platform-cip-manage: platform management
2. Migration and splitting modules
Migrating the common module: This is a pre-dependent basic module. Migration and integration are relatively simple. The main task is to change the package name and path referenced when relying on it.
Split the platform-cip module: one into three.
The relationship among the four modules is that manage depends on common, api and manage are independent of each other, but both depend on manage.
Code refactoring: extract the entity classes ApiRequest and ApiResponse originally located in the api location to the common module
Of these four modules, only the manage module has a front-end page, and the other three are class libraries. The following uses the low-code configuration function of the development platform to rewrite the module, and also introduces the usage and precautions of the low-code configuration function.
Reimplement the manage module
Let’s first review the overall framework and steps, as shown in the figure below.
Next, we will talk about the specific steps and precautions in detail.
1. Create a new module
| Attributes | illustrate |
|---|---|
| application | Which application does the module belong to? Considering the limited number of applications and few attributes, no new entities are created, and a data dictionary is used for simplified management |
| name | The Chinese name of the module, nothing to say |
| coding | Module code, key attribute, used as a unique identifier, and also the directory name of the front-end and the package name of the back-end module |
| abbreviation code | The module's abbreviated code, used to prefix the library tables for that module |
| package path | The package path where the module is located |
| to sort | Used for sorting, will not be repeated below |
| Remark | It is a note, and will not be repeated below |
In the above example, because cip itself is an abbreviation, the difference between encoding and abbreviation cannot be reflected.
To give another example, such as the system management module, the encoding is system, the abbreviation is sys, the encoding system is used for the front-end directory name and the back-end package name, and the abbreviation sys is used for the naming prefix of the module library table.
In the process of creating the module, it was found that the package path of the original refactored manage module did not follow the low-code configuration specification, and there was an extra section of manage in the package path. This is simple, just refactor, remove the package path manage, keep the module name unchanged, the 4 modules removed from the interface platform, in fact, only the manage module has front-end functions corresponding, and the other three modules are class libraries, so will It is also worthy of the name as the main body of the interface platform.
2. Create a new entity
First choose a simple entity as an example.
The interface platform first needs to maintain the docked application data. Here we take the application entity as an example.
| Attributes | illustrate |
|---|---|
| module | The module that the entity belongs to, select from the data list configured in step 1 above |
| name | Entity Chinese name |
| coding | Entity English encoding, multiplexing, as back-end entity class name, library table name |
| author | Developers used to label entities will generate @author attributes in code class annotations |
The development platform has built-in processing logic. When saving an entity, it will automatically create an entity model with the same name and automatically set it as the main model, reducing repetitive work and improving development efficiency.
Click the save button to return to the list, click the configuration button on the right of the application line to enter the entity configuration page, as follows: the
navigation on the left is divided into two parts, one is the data model, and the other is the view.
3. Configure the data model
| Attributes | illustrate |
|---|---|
| parent model | The reuse and expansion of the model is realized through the concept of inheritance, and the business model is preset, including the identity, creator, creation time, modification person, modification time, logical deletion flag, version number (optimistic lock control), and inheriting the model will Automatically possesses these common properties and can be extended |
| name | Chinese name |
| coding | English encoding, multiplexing, as the library table name (actually the second half of the library table name, the module abbreviation code will be added in front to avoid the problem of duplication of library table names caused by entities with the same name under different modules) |
| Whether the main model | For each entity, there may be multiple models below, and a main model needs to be marked as the main body, such as the sales order entity, which is composed of orders and order details. At this time, mark the order as the main body |
| Is it self-associated | Some entities are self-associated, such as organizations. After the self-association is marked, the code will perform additional processing in code generation, such as adding an interface for obtaining tree-structured data in the controller. |
4. Configure model properties
Click the "Configure Attributes" button on the row record to open the model attribute configuration function, as follows:
Click the Add button to create a new attribute:
| Attributes | illustrate |
|---|---|
| name | attribute Chinese description |
| coding | Attributes are encoded in English, corresponding to the attributes in the java entity class, following the small hump naming convention, the platform generates database field names based on this attribute, and the hump naming style is automatically converted to the serpentine style (all lowercase, words are separated by underscores) |
| type of data | The data type of the attribute, including basic types (such as text, integer, long integer, floating point number, date time, etc.) and complex types (such as data dictionary, entity), which can be extended |
| control type | The default display control of the attribute, which changes automatically with the data type, such as text, corresponding to normal text, long text and rich text. |
| The maximum length | The attribute length setting corresponds to the field length setting of the library table. |
| Defaults | The default value is filled. When creating a new entity, the service layer will automatically read the configuration and set the default value corresponding to the attribute. |
| Is it nullable | Whether the attribute is allowed to be empty, if it cannot be empty, the verification annotation @NotBlank will be automatically added when generating the vo object. |
| Is it unique | Whether the value is unique, if unique, when the service is generated, data validation logic will be automatically generated before creation or modification. |
| unique reference | Keep it empty for globally unique verification. Other attributes of this entity model can be selected to represent the unique value of this attribute. It is usually used in parent-child data structures and cannot be repeated under the same parent. |
| Is it the main attribute | Whether the mark is the main attribute, this attribute is regarded as the main display attribute of the entity, when the entity is used for other entity associations, this attribute is used as the display value |
| Is it the superior attribute | Used to mark whether the attribute is associated with the parent |
Some of the attributes here seem to have nothing to do with model attributes, such as control type, display format, etc., and it is more appropriate to put them in the view configuration class. The reason why it is placed here in the entity model attribute is from the perspective of development efficiency. For the same model, multiple views will be configured, attributes will be used multiple times, and the default display of attributes will be configured in entity attributes to simplify the configuration of view links, avoid repeated configurations, and improve efficiency.
Similarly, create other attributes.
When the data type is selected as data dictionary, the dictionary type selection control will appear automatically, and the data dictionary set in the system will be selected.
There will also be a drop-down list and a radio button group for the control type. Usually, when there are few dictionary items, there are 2-3 items. Using a radio button group is easy to operate and intuitive to display. If there are many dictionary items, it will take up a lot of page display area. At this time, it is better to use a drop-down list.
After the dictionary type is selected, the default value will also be automatically loaded. You can choose whether to set the default value and which dictionary item to use as the default value according to the actual situation.
All properties are configured as shown in the figure below.
Come here today, the view part is super complicated, and I will leave it for the next topic.
Development platform information
Platform name: One Two Three Development Platform
Introduction: Enterprise-level general development platform
Design information: csdn column
Open source address: Gitee
open source protocol: MIT
welcomes favorites, likes, and comments. Your support is the driving force for me to move forward.