Struts and hibernate: J2EE architecture Data Representation

Hibernatestruts Data Structure beanweb

This article describes the Data Representation Methods at each layer in the J2EE architecture, including: 1. formbean is the data representation at the web layer; 2. Vo is the data representation at the business layer; 3. The data in the persistence layer is po. Form bean cannot be passed to the business layer. Po can appear at the business layer in specific circumstances, such as Hibernate, instead of VO, but both Po and VO must be used at the business layer, the control at most reaches the web layer and cannot be spread to the view.

 

In the Struts + hibernate structure, the PO generated by hibernate 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 on 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 persistent layer is Po, and its data comes from the database. The data in the persistent layer is represented by CMP.

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, it has many set attributes. 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.

BTW(By the way ):

Jdo1.x is not as powerful as Hibernate, And po cannot be separated from the persistent layer. Therefore, Vo must be used at the business layer. Therefore, a large number of VO and Po conversion operations must be performed at the business layer. Compared with hibernate, programming is cumbersome.

Of course, the theory is the same thing, and the actual operation does not have to be done in this way. You can choose to be flexible in the actual project, add a little bad smell, and improve the development efficiency. However, it is best to keep things close together in large projects. Otherwise, the revision will be painful.