Shulou(Shulou.com)06/02 Report--

This article is to share with you about the use of J-Hi generators. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Database correlation

Different database script files will be generated for different database J-Hi, and the generated files will be temporarily stored in the relevant database (MSSQL/MYSQL/ORACLE) subdirectory under the web/db directory, and the files in this directory will be cleaned every time they are generated. The resulting file is as follows:

Xxx.sql defines the creation of database tables for all entities under the service (except enumerated entities)

Xxx_BaseData.sql is used to insert relevant data for system tables for entities under this service. System tables include menus, permissions, enumerations, and so on. Through this file, menu information and permission information related to entities will be inserted into the system table at one time.

Java correlation

Because there are many covered frames in Java, the content generated by different frameworks and different technologies will be different. Let's divide it according to the principle of three-tier structure:

Data access layer

The xxx.dao package is the total package of the data access layer, and there will be corresponding subpackages for different ORM frameworks, such as hibernate, ibatis (ibatis2), ibatis3 and so on.

* DAO.java: this is an interface under the dao package to regulate the differences between different frameworks.

Hibernate subpackage:

* the concrete implementation class of DAOHibernate.java:hibernate data access, which inherits BaseDAOHibernate, thus realizing the encapsulation of hibernate

* * .hbm.xml: this file is a mapping file for hibernate

We manage two different versions of ibatis into two subpackages because there is already a big difference in the underlying implementation between ibatis2 and ibatis3, both in terms of internal operating principles and configuration files are basically subversive changes.

Ibatis subpackage

* A physical class for DAOIbatis.java:ibatis2 data access, which inherits BaseDAOIbatis to encapsulate Ibatis2

* * .ism.xml: the mapping file of ibatis2. The suffix ism refers to ibatis sql mapping.

Ibatis3 subpackage

* A physical class for DAOIbatis3.java:ibatis3 data access, which inherits BaseDAOIbatis to encapsulate Ibatis3

* * .ism3.xml: the mapping file of ibatis3. The suffix ism refers to ibatis3 sql mapping.

Business logic layer

The business logic layer J-Hi uses spring, so it is roughly the same as the standard structure of spring.

The xxx.service package is the total package of the business logic layer, under which the interface is defined.

* Manager.java: the interface class file of business logic. By default, the method of adding, deleting, querying and modifying entities is generated. If you want to do permission control in the business logic layer, you can call the * Security*** () method.

Under the xxx.service.impl package

* ManagerImpl.java: a concrete class of business logic, which inherits the ManagerImpl class. If it is a specific business logic, it must be implemented in the form of handwritten code in this class.

AppContext-xxx.xml: is the configuration file for spring, placed under the xxx package

Presentation layer

The xxx.action package is the total package of the presentation layer, and there will be corresponding subpackages for different presentation layer frameworks, such as webwork, struts and other subpackages.

* PageInfo.java: under the total package of action, this class is frame-independent. In fact, this class records a POJO of page information, which mainly includes three parts: 1) page: number of rows, current pages, etc.; 2) filter (filter): that is, query condition; 3) sorter (sorter): that is, reverse order

Webwork subpackage:

* ListAction.java: the action called when querying the page

* * .RemoveActoin.java: the action invoked when the record is deleted

* * .RemoveAllActoin.java: the action invoked during batch deletion

* SaveAction.java: the action called when the record is saved

* * .ViewAllActoin.java: actions invoked when viewing records

Configuration file for xwork-xxx.xml:webwork

Compared with webwork, struts has only one class file, so all the actions are implemented through method naming calls. The reason why we make the two generation methods is to consider that users will have different programming preferences, so we provide two generation modes between different frameworks to adapt to the differences in programming preferences.

Struts subpackage:

At present, the platform has abandoned its support for struts1.x, so struts is related to struts2 as the premise.

* Action.java: this Action includes all page call actions and is scheduled by method naming.

Configuration file for struts-xxx.xml:struts2

POJO and others

In the total package where the xxx.model package is POJO, a POJO is actually made up of two class files, namely

* Abstract.java: this class is an abstract class of POJO

* .java: this class is the concrete class of POJO

The reason for this is to prevent handwritten code from being overwritten by files generated by the generator.

* .java: if there is an enumerated entity in the definition, there is also a constant class file under the model package that generates the corresponding enumerated entity

* *-conversion.properties: if the entity has a slave entity, that is, the master-slave structure, the generator generates the file corresponding to the master entity in order to adapt to the objective encapsulation of the page information by the presentation layer framework

Xxx--security.properties: this file is placed under the xxx package and is a configuration file for the mapping information of permissions

Page dependent

In the future, the generator will vary according to the selected template, and the corresponding generated pages will be very different. Now take the classic template of the current platform as an example.

* List.jsp: query page

* Edit.jsp: edit page

* View.jsp: view the page

* * .js: the javascript file corresponding to the JSP file

Source data correlation

* .hsc.xml corresponds to each service. The platform generates a description file of the source data in the WEB-INF/matadate directory. This file records all the information that defines the model. The meaning of hsc is: hi service config

A solution based on platform generator to avoid manual code being overwritten

If you use this platform to develop, theoretically more than 80% of the code is generated. This raises a new question-how can I ensure that the code I rewrite or add manually will not be overwritten by the files generated by the generator?

Considering the above problems, the generator has the following rules when generating files:

The generator repeatedly generates and overwrites the following classes and files:

I. abstract classes under the model.original package

ii. * PageInfo class under the action package

iii. The * * .hbm.xml file under the model package

iv. AppContext-***.xml file under the service root package

v. * *-security.properties file under the service root package

vi. Xwork-***.xml file under src root

In addition to the above files, the generator will determine whether other files exist when generating other files, and will no longer generate or overwrite the contents of the generated or manually modified class or configuration file.

As you can see from the rules of repeatedly generated files, the generator only generates repeatedly:

1) classes or configuration files that are closely related to entity attributes, such as abstract classes of the model and * * PageInfo, * *. Hbm.xml, because the name or number of attributes in the entity changes, the generator should adapt to the change of the entity attributes.

2) configuration files related to the whole service, such as xwork-***.xml, appContext-***.xml, etc., because there will be multiple entities under one service, and the generator has to adapt to the increase or decrease of entity databases under the service.

3) for those class generators that are related to entities and not related to services or entity attributes, all classes under dao, service, action will be generated only once to ensure that your handwritten code will not be overwritten by the generator

In platform-based development, due to the use of generator generation, you can use the following solutions to prevent your handwritten code or configuration from being overwritten by the generator

i. If you want to implement an interface or method for a model class, rewrite the concrete class under the model package. This class will only be generated once. Be careful not to modify the content in the abstraction under the original package.

ii. If you want to modify the configuration file of the presentation layer, take xwork-test.xml as an example, the action should be 1) create a new xwork-test-customer.xml configuration file, 2) write the actoin you want to modify or add in the file (even if the action name is not duplicated with the only action name of xwork-test.xml, the system will give your action priority) 3) when introducing the configuration file in the xwork.xml file, be sure to put it under the xwork-customer.xml reference. Only in this way will the action with a complex name call your configuration first.

iii. If you want to modify the configuration file of the business layer, take appContext-text.xml as an example, the action should be 1) create a new appContext-test- customer.xml configuration file, and 2) add your own configuration information to the file. Note that the new file name must start with appContext.

iv. If you want to modify the permission configuration file, take test-security.properties as an example, the action should be 1) create a new test-customer- security.properties configuration file, 2) add your configuration information to the file. Note that the new file name must end with-security. * if you want to delete some configuration items in the generated configuration file (that is, some url or methods are not required for permission control), it is recommended to handle them uniformly after the completion of the whole project.

Thank you for reading! This is the end of this article on "what is the use of J-Hi generators?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.