1. The introduction
I started to work in July last year. At the beginning, I was successively assigned two tasks of making basic pages, namely the routine addition, deletion, modification and check, including the VUE file of the front page, the entity class of the back end and the interface and implementation class of each logical layer. A total of 9 files need to be created, including 1 VUE, 7 Java and 1 XML.
While you can use MybatisGenerator to automatically generate entity classes and Mapper layer files from database tables, the logical layer above that needs to be written manually. Ctrl+C, Ctrl+V, then according to the specific entity class name to modify, back and forth spent an hour to make a base page through. I thought it was too much trouble, so I came up with the idea of writing a code generator that would generate 9 files in one click, so as to say goodbye to copy-and-paste. The effect is as follows:
2. The technical points
- Based on code template generation, the common FreeMarker was used as the template engine.
- In order to simplify the operation, a GUI was made to encapsulate the existing MybatisGenerator with the newly written generating code logic. Use JavaFX, you can drag controls, pretty easy.
- SQLite is used to store location information of build files, database connection information, and switch between projects.
Problem 3.
Some of the problems encountered with the following documentation:
-
After MybatisGenerator generates the entity class (Java file), the entity class needs to be encoded into a class file and loaded into the JVM to read the entity class attributes through reflection. The implementation steps are as follows:
- Read the contents of a Java file
- JavaCompiler dynamically compiles to generate class files
- Add the path of the class file to the classpath by reflection using the addUR L method of the ClassLoader (the main reason for adding the classpath is that the final program is packaged as a JAR package, The runtime generated class file is not in the JAR, so its path is not in the classpath.)
- Loading classes (class.forname)
-
When developing with an IDE, resource files can be successfully found using the File class:
File configFile = new File("generatorConfig.xml"); Copy the code
But packed into a jar package, even the resource files packaged together, and then is unable to file: / e: / codeGenerator jar/generatorConfig. This form of XML file URL to find files.
This is because the JAR package is a separate file, not a folder, and the contents of the JAR package need to be retrieved through the getResourceAsStream method provided by the ClassLoader.
InputStream configFile = Thread.currentThread().getContextClassLoader().getResourceAsStream("generatorConfig.xml"); Copy the code
4. Think about
In the “Alibaba Java Development Manual”, four application layers are recommended, namely, Web layer, Service layer, Manager layer and DAO layer. In the development process, we often see that each layer needs to be interface oriented programming, such as xxxManager. This was done to achieve the principle of “closed to modification, open to expansion”.
The reality is that there is usually only one implementation class for an interface, such as xxxManagerImpl, and most code usually does not extend. As mentioned above, adding, deleting, modifying and checking a simple basic data requires 7 Java classes, which increases the amount of code. Inevitably some are using the smell of an interface for the sake of using it.
Do you need to program to interfaces?
Let’s consider the advantages and disadvantages of not using interface-oriented programming when an interface has only one implementation class.
The benefit, of course, is that we only need to write and maintain one piece of code (the implementation class), which reduces the amount of code.
The downside is uncontrolled control of class information exposure. For example, if we want to implement method-level caching with AOP and use the annotation tag method, if we make the mistake of marking the annotation on the private method, since Cglib-based AOP creates the proxy by subclassing it, that AOP will not work; However, if the dynamic proxy is based on the interface, this problem does not occur due to errors.
Finally, try to give a tentative answer to this question:
In large teams developing enterprise-oriented applications, use interface programming to avoid unexpected risks.
However, if the team size is small, the risk of not using the interface is understood, the risk can be accepted, and the business logic changes frequently, instead of enterprise application development, the implementation class development can be considered directly without using the interface.