The Automatic Code Generation mentioned here refers to the code from the database structure>, which must be indispensable in O/R Mapping, including the generation of Entity Class and Xml Mapping File, in database-centered development (especially MIS), automatic code generation can be used for rapid development and easy maintenance. For a long period of time, I no longer execute the join SQL statement operation, because for the row operation, I implement it through EntityManager, while for the rowset operation, I implemented it through a compromise (For details, refer to my SinoLib ).
There are two methods to automatically generate code: Template and script. The template method is more common and can meet the needs of most situations, some custom tags are inserted and parsed by programs. The script execution method is very flexible and powerful, because in many cases, the requirements are special, therefore, it is difficult for common templates to generate such code.
Ceg and CodeDG are two Automatic Code Generation software I have written, namely the implementation of the above two methods. For a long time, I have used CEG to generate several of my O/R Mapping frameworks, and before SinoLib, it can complete the task well. However, SinoLib uses an Xml file to describe the table object (which may be a table, view, or select) corresponding to the object class because of the independence of the data platform, however, due to its special format, the Ceg cannot be generated through the template. I can only manually modify it in the generated Xml file. Another feature that cannot be met by Ceg is that when a Java class file is generated, the first letter outside the class needs to be capitalized, while the table name is all lowercase. In this case, if the template method is supported, only one TAG can be added, for example, <Ucase>. Therefore, it is inconvenient to expand the template method, and the functions are limited. In terms of software implementation, the script method is actually much easier than the former method.
Because ScriptControl was used in the project for script support some time ago, it was decided to develop CodeDG to make up for Ceg's shortcomings and completely replace Ceg, in fact, I had the idea about script support a long time ago, but I never implemented it. After more than one day of development over the weekend, CodeDG was completed. Its features include:
1. compatible with VBA syntax
2. Similar to ASP embedded script syntax, and supports <% =... %>
3. Supports functions and process definitions, and adds IIF functions and App objects.
4. Access the structure information of the current database through the Schema and Table objects passed in by the software
In fact, CodeDG does not automatically generate code. It is mainly a platform for Retrieving Database structure information and parsing and executing scripts, you can expose database structure information to your scripts through a unified interface (currently only MSSQL and Access tables are supported). You can use VBA to create a file to generate the required code, you can also call an Excel or Word Application to generate a data dictionary. The entire expression mode is very similar to ASP. You can use dynamic scripts to create static pages. Of course, you can also use MsgBox to perform more complex operations.
Adding script support is actually very easy in your program. You can define some of your unique syntax features, such as CodeDG's <% .. %> include the script, and then add the objects in the program to the ScriptControl object through the AddObject method, so that the script can access these resources related to your program, and then execute the script, to obtain the execution result, you can use two methods: public-level variables in the module and FUNCTION-based direct return values.
Although this Post is not. Net, CodeDom in. Net can also implement similar functions and be more powerful.