Abstract: This article was originally published on CSDN by the technical team of Grape City. Please indicate the source of the reprint: Grape City official website , Grape City provides developers with professional development tools, solutions and services to empower developers.
Most programmers who are exposed to low-code for the first time will be entangled in one question, why the more powerful the low-code development platform, the less likely it is to provide the function of exporting source code?
To answer this question, we have to review the history of low-code development. In fact, low-code tools that support exporting source code are products of the previous era. Now, most low-code vendors that still have research and development capabilities and are willing to promote productization have completed or are in the process of transforming to metadata-driven.
Standing in 2023, the diversity of manufacturers in the domestic low-code industry is too strong and mixed. In order to clarify the differences and advantages and disadvantages of code generators and metadata drivers, we can use the visual development of Windows desktop programs as an analogy. After all, Visual Studio can be regarded as one of the originators of low-code.
Initially, Visual Studio and earlier Visual Basic adopted the technical solution of code generator when designing the interface. The IDE directly translated the user's actions of dragging and dropping controls and setting properties into codes for operating these controls. Users can directly obtain these codes, and if necessary, they can expand the visual development capabilities of VS by modifying these codes.
(WinForm code generated by Visual Studio)
This practice has a long history, dating back to the 1990s. It is a bit obvious that this method is the easiest to implement for the IDE, and it is more convenient for users to modify it by hand. However, if users really use this method to develop a large-scale project and maintain it for a long time, they will find that it is easy to allow developers to modify the part of designer generated code , not to mention how to understand the uncommented code generated by the designer As a result, subsequent visualization operations flush out some manually modified codes, and even the visualization design page cannot be opened. Visual development has become a " one-shot deal ". In the long run, the development efficiency and maintainability advantages brought by visual development are very limited. After all, software is not achieved overnight, but requires long-term maintenance and iteration to fully realize its value.
In order to solve this problem and make visual development effective for a long time, Microsoft referred to the HTML technology used in the Web when developing a new generation of desktop applications, and launched WPF technology in 2008. When using Visual Studio to develop the interface of a WPF application, the IDE saves the result of the user dragging and dropping controls and setting properties as metadata in XAML format (a type of XML). Because XAML itself is the result of visual design , it can correspond to the visual designer one-to-one, and the user's modification of XAML can be fed back to the visual design page in real time. This is the default Split view of Visual Studio. Users can switch between visual development and coding extensions at any time, adapting to the development phase and maintenance phase.
(WPF metadata generated by Visual Studio)
Switching from process-oriented code to result-oriented metadata, visualization development has gone from "one-shot sale" to continuous coverage, and visualization development has finally exerted its due value. The following is a comparison of the characteristics of the two technical routes:
| evaluation standard | generate source code | generate metadata |
|---|---|---|
| Productization degree | Low (requires obfuscation to protect copyright) | high |
| Recommended way to extend development | Modify the generated source code | Develop plugins (metadata tags) |
| Visualize development coverage | when created | full life cycle |
| overall maintainability | Difference | good |
| overall development efficiency | Low (closer to coding development) | high |
Back to the question at the beginning of the article. As a programmer, if you want to use low-code development tools to build and maintain a software project for a long time, please abandon the idea of "exporting source code" as soon as possible, because the greatest value of low-code is not like configurable code templates. Create a page or business logic , but reduce long-term development and maintenance costs. Choose a low-code development platform with a high degree of productization (focusing on the flexibility of page and logic design, documentation, tutorials, and developer communities ) and a metadata-driven technical route, such as the low-code development platform of Grape City. If necessary, expand the development in a manner similar to "plug-in" or " subsystem integration " provided by the manufacturer.
If you are doing a "one-shot deal" project, and the maintenance work will be completely handed over to Party A in the future, then don't use low-code . Reading someone else's code is a pain, and machine-generated code without comments is a nightmare. We are all programmers, why bother colleagues?