Struts + H ibernate on J2EE Data Representation

In the Struts + H ibator structure, the PO generated by H ibernate should not be directly transmitted to JSP. Whether it is iterator or list, this is a design error.

Let's talk about the data representation at each layer in the J2EE architecture:

The data in the web layer is formbean, and the data comes from HTML form post

The data at the business layer is vo.

The data in the persistence layer is Po, and its data comes from the database. The data in the persistence layer is represented by CMP, for example. In a standardized J2EE architecture, data representation of different layers should be restricted within the layer rather than spread to other layers, which can reduce the coupling between layers, improve the overall maintainability and scalability of the J2EE architecture. For example, if the logic of the web layer is modified, you only need to modify the formbean structure without touching the code modification at the business layer and persistent layer. Similarly, when a small adjustment is made to the database table, you only need to modify the persistent layer data representation without touching the Business Layer Code and web layer code.

However, due to the powerful functions of hibernate, such as dynamic Po generation, the status management of PO can be separated from the session, so that in the J2EE framework applied to hibernate, PO can act completely as vo, therefore, we merge Po and VO, collectively referred to as po.

Let's talk about the major differences between actionformbean and the Po at the persistent layer:

In simple applications, there is almost no difference between actionformbean and Po, so many people simply use actionformbean to act as po, so actionformbean goes from the JSP page to the servlet control layer to the business layer, then, it passes through the persistence layer and maps to the database table all the time. It was a success!

However, in complex applications, actionformbean and Po are separated, and they cannot be the same. Actionformbean is one-to-one correspondence with form forms on the webpage. What elements are contained in form and what attributes are contained in bean. The PO corresponds to the database table. Therefore, if the database table is not modified, the Po will not be modified. If the process on the page is inconsistent with the database table field, so how can you replace Po with actionformbean?

For example, the user registration page requires you to register the basic information of the user. Therefore, the HTML form contains the basic information attributes. Therefore, you need an actionformbean for one-to-one correspondence (Note: it is a one-to-one correspondence ), each bean attribute corresponds to a text box or a selection box.

What about the user's persistent object? What is the difference between its attributes and actionformbean? It has some set attributes not available for actionformbean, such as user permission attributes, user group attributes, and user posts. It is also possible that there are three attributes in actionformbean: First name, middle name, last name, in my user, this persistent object is a name object attribute.

Suppose that you provided the first name on my registration page, then actionformbean is the attribute. Later, I want you to provide the full name. You need to change actionformbean and add two attributes. However, the PO should not be modified because the database has not been changed.

So how should we make a reasonable design in a complete J2EE system?

JSP (View) ---> action form Bean (module) ---> action (Control)

Action Form bean is the data representation of the web layer. It corresponds to the HTML page form. As long as the operation process on the Web page changes, it must be modified accordingly, it should not and cannot be passed to the business layer and the persistent layer. Otherwise, once the page is modified, it will always be implicated in a large area of code modification at the business layer and the persistent layer, it is a disaster for Software maintainability and scalability, and actiont is its boundary. So far!

Action (Web Control) ---> business bean ---> Dao ---> ORM ---> DB

The po is the data representation of the business layer and the persistent layer. It flows between the business layer and the persistent layer and cannot be transmitted to the view of the web layer, and actionservlet is his boundary, so far!

Then let's take a look at the entire architecture process:

When a user accesses a webpage through a browser, a page is submitted. So the action obtains the formbean, reads the formbean attribute, constructs a po object, calls the Bean class at the business layer, completes the registration, and redirects to the successful page. After receiving the Po object, the business layer bean calls the DaO interface method to perform Persistent Object operations.

When a user queries the information of a member, he uses the full name for the query. Therefore, the action obtains a usernameformbean that contains three attributes: First name, middle name, last name, then, Action reads the three attributes of usernameformbean, constructs the name object, calls the business bean, passes the name object to the business bean for query.

After the service bean obtains the name (Note: The name object is only an attribute of the user) object, it calls the DaO interface and returns a user's po object. Note that this user is different from the userformbean used on the web layer, he has many collection attribute drops. Then the business bean returns the user object to the action.

After the action obtains the user, it extracts the basic attributes of the user (if the set attribute is not needed), constructs the userformbean, and then requests the userformbean. setattribute (...), then redirect to the query result page.

The query page obtains the actionformbean in the request object and automatically calls the tag to display it.

Summary:

Form bean is the data representation of the web layer, which cannot be passed to the business layer; Po is the data representation of the persistence layer. in specific circumstances, such as in hibernate, it can replace vo in the business layer, but both Po and VO must be used in the business layer. The control at the web layer can be reached at most, and cannot be spread to view.

Data conversion between form bean and Po is performed in action.

 

VO: Value Object and view object

Po: Persistent Object

Qo: query object

Dao: Data Access Object

Dto: Data Transmission object

 

 

Dto Summary
DTO is the abbreviation of a data transfer object.
Dto mode or VO mode refers to encapsulating data into common JavaBeans and transmitting data between multiple layers of J2EE.
Similar to a messenger, DTO synchronizes messages in the system.
The JavaBeans can be a data model.
A common method is to create a model class for an object. This class only contains the getter and setter of all the fields of this object. For example, if the user object has the name and password fields, a usermodel class is created. The public methods include getname, setname, GetPassword, and setpassword. In this way, you can pass userform as a parameter to other functions.
The data transfer object (DTO) mode is used to solve the following problem: for example, for an object bean, there are many fields in the corresponding database table, therefore, we may have many parameters in the create method of the home interface and the ejbcreate method of the enterprise Bean class, which leads to insufficient elegant methods. We can define a simple Java class (implementing the serializable Interface), define some attributes, and provide the corresponding get and set methods to solve the above problems.
Model, domain object, and DTO relationships:
1. Analyzing and refining model is the starting point of system design
2. At the beginning of the system design, the three aspects were basically unified
3. After the system is complicated, DTO may be implemented by combining multiple models;