Java EE application built based on SSH2 framework (2)

Iv. Data Transmission, data model and Dozer
Data transmission is a problem that programmers need to consider when implementing various functions, from the establishment of data models, to the conversion of data models, from the validation of data legitimacy, to the conversion of data types, we should always be careful and carefully designed and organized. Data models and data transmission can be simple and complex, depending entirely on the experience and intent of the designers. Of course, the scale of the project is also a factor we should consider. A small project really does not need to complicate the problem.

 

 

First, we should consider the process of data model changes when data is transmitted from a View to a database. The user inputs data from the interface. At this time, the data has no structure and is scattered and unorganized. After the data is submitted to the Controller, the rigor of OOP is taken into account, and the encapsulation of data is also taken into account, it encapsulates scattered and unorganized data into a Value Object (VO) Object. VO is a JavaBean Object and transmits it to the business class. When the data model is complex, the method parameters and return values of the service class should be a set of VO or VO. VO is converted to a PO (Persistence Object) and then transmitted to DAO. DAO calls the Hibernate API for persistent data. To put it simply, the data model exposed by the business class is VO, and the data model exposed by DAO is PO.

 

 

The data model changes from the database to the view layer are exactly the opposite. Hibernate converts the records in the database to PO, and the PO is transferred to the business class and then converted to VO, VO is transferred to the view layer for display.

 

The preceding conversion process is as follows:

Why do I need both PO and VO? As mentioned above, this is not necessary. If the project is small, simply use the PO. However, PO has the following Disadvantages:

 

 

V PO reflects the physical model of the database, and there is a certain risk of exposure to PO;

V PO is too rigid to adapt to unpredictable business needs;

V PO is synchronized with the database in a persistent state, which may lead to accidental data modification;

V PO causes program robustness.

 

 

VO does not have the disadvantages of PO. In contrast, VO is more flexible and can adapt to changes in various needs. The following are the differences between PO and VO:

 

 

V VO is created with the new Keyword and collected by GC. PO is created when new data is added to the database, and deleted when data in the database is deleted. In addition, it can only survive in one database connection, and is destroyed when the connection is closed;

V VO is a value object. To be precise, it is a business object that is stored at the business layer and used by the business logic. The purpose of its survival is to provide a place for data to survive. PO is stateful, and each attribute represents its current state. It is the object representation of physical data. Using it can decouple our program from physical data and simplify the conversion between object data and physical data;

The attributes of v VO vary according to the current business. That is to say, each of its attributes corresponds to the names of the data required by the current business logic. PO attributes correspond to database table fields one by one;

Generally, there is only one v PO, but the corresponding VO may have multiple.

 

 

Let's take a simple example to illustrate the differences between VO and PO: for example, to implement the user registration and login functions, create a user table in the physical model, the fields are user ID (ID column), user name, password, registration date, and so on. The ing attribute of these four fields should be defined for PO. Now, we can implement the user registration function. In order to receive the registration information entered by the user, VO must be defined. The registration user must enter the following information: User Name, password 1, password 2, this is exactly the property of VO. When implementing the user login function, the user must enter only the user name and password. Therefore, the VO has only two attributes: user name and password. We can see that PO focuses on physical models, while VO focuses more on users' actual needs. As shown in:

 

Because data transmission is bidirectional, there is a problem of mutual conversion between VO and PO. This will cause programming troubles. We always need to retrieve data using the getter method, the setter method is used to assign values to attributes of the other party. In many cases, attributes are cumbersome, and the Dozer tool can simplify this problem.

Dozer (http://dozer.sourceforge.net/) is a JavaBean ing tool that can realize mutual assignment between object property values. Dozer supports simple type ing, composite type ing, bidirectional ing and recursive ing. By default, dozer can assign values between attributes with the same type and name. If the attribute names are different, the values must be in xml (dozerBeanMapping. xml) is specified in the configuration file. If you do not need to assign values to each attribute of the JavaBean, you can also specify them in xml. For the Xml definition, see http://dozer.sourceforge.net/dtd/dozerbeanmapping.dtd. the structure of the statement is as follows:

 

 

<? Xml version = "1.0" encoding = "UTF-8"?>

<! DOCTYPE mappings PUBLIC "-// DOZER // dtd mappings // EN"

Http://dozer.sourceforge.net/dtd/dozerbeanmapping.dtd>

<Mappings>

<Configuration>

<Stop-on-errors> false </stop-on-errors>

<Date-format> MM/dd/yyyy HH: mm </date-format>

<Wildcard> true </wildcard>

</Configuration>

<Mapping>

<Class-a> com. denny_blue.dozerdemo.Book </class-a>

<Class-B> com. denny_blue.dozerdemo.CookBook </class-B>

<Field>

<A> name </a>

<B> bookName </B>

</Field>

<Field>

<A> author </a>

<B> author </B>

</Field>

</Mapping>

</Mappings>

 

 

<Class-a> specify the source object to be copied, <class-B> target object to be copied, <a> attribute name of the source object, and <B> attribute name of the target object. By default, wildcard is true. By default, all attributes are mapped. If it is false, only the attributes configured in the xml file are mapped.

 

 

The Book and CookBook classes are defined as follows:

 

 

Public class Book {

Public Book (){

 

}

Public void setAuthor (String author ){

This. author = author;

}

Public String getAuthor (){

Return (this. author );

}

Public void setName (String name ){

This. name = name;

}

Public String getName (){

Return this. name;

}

}

Public class CookBook {

Private String bookName;

Private String author;

Public CookBook (){}

Public String getBookName (){

Return (this. bookName );

}

Public void setBookName (String bookName ){

This. bookName = bookName;

}

Public String getAuthor (){

Return (this. author );

}

Public void setAuthor (String author ){

This. author = author;

}

}

 

 

The following is the test code:

 

 

Book book1 = new Book ();

Book1.setAuthor ("dennis ");

Book1.setName ("dozer demo ");

DozerBeanMapper mapper = new DozerBeanMapper ();

Book2 = (Book) mapper. map (book1, com. denny_blue.dozerdemo.Book.class );

CookBook cookBook = new CookBook ();

List myMappingFiles = new ArrayList ();

MyMappingFiles. add ("dozerBeanMapping. xml ");

Mapper. setMappingFiles (myMappingFiles );

CookBook = (CookBook) mapper. map (book1, CookBook. class );

System. out. println ("cookBooks name:" + cookBook. getBookName () + "cookBooks author:" +

CookBook. getAuthor ());

}

 

 

You can use mapper. setMappingFiles () to set the ing file. You can add multiple configuration files or write all mappings in one configuration file. The most basic usage method is described here. In order to implement the modular application of Dozer, I specifically wrote a VoPoConverter class to simplify the call of Dozer.

 

 

Package com. aptech. util;

Import java. util. ArrayList;

Import java. util. List;

Import org. dozer. DozerBeanMapper;

Import org. dozer. Mapper;

/**

* Classes for conversion between VO and PO

*/

Public class VoPoConverter {

/**

* VO and PO are converted to each other. The source object's attributes with the same name are copied to the target object.

* Premise: both the source and target objects must exist.

* @ Param src Source object

* @ Param desc target object

*/

Public static void copyProperties (Object src, Object desc ){

If (src = null) return;

Mapper mapper = new DozerBeanMapper ();

Mapper. map (src, desc );

}

/**

* VO and PO are converted to each other. Create an object first, and then copy the Same Name attribute of the source object to the target object.

* @ Param <T> target type

* @ Param src Source object

* @ Param descType