Data representation of Java EE in struts+hibernate structure

Source: Internet
Author: User
Tags form post html form html form post html page

In struts+hibernate this kind of structure, is should not pass the PO that hibernate produces directly to JSP, whether he is iterator, or list, this is a design error.

Let me talk about the data representation for each layer in the Java EE architecture:

The data representation of the Web layer is Formbean, and the data comes from the HTML Form POST

The data representation of the business layer is VO

The persistence layer's data representation is the PO, whose data originates from the database, and the persistence layer's data represent such as CMP. In a canonical Java EE architecture, the data representation of different layers should be confined to the layer, and should not be spread to other layers, which can reduce the coupling between layers, and improve the maintainability and scalability of the Java EE architecture as a whole. For example, the logic of the Web layer has been modified so that only the Formbean structure needs to be modified without touching the code modifications of the business layer and the persistence layer. Similarly, when a database table is adjusted little, it is only necessary to modify the persistence layer data representation without touching the business layer code and the Web layer code.

However, due to the powerful functions of hibernate, such as the dynamic generation of Po,po state management can be separated from the session, so that in the application of the Hibernate Java EE Framework, PO can serve as VO, so we combine PO and VO, collectively referred to as PO.

Let's talk about the big difference between the Actionformbean and the persistent layer of the PO:

In simple applications, Actionformbean and PO are almost indistinguishable, so many people simply use Actionformbean to act as a PO, so Actionformbean from the JSP page to the Servlet control layer to the business layer, and then through the persistence layer, The last one is mapped to a database table. It's a pole!

But in complex applications, Actionformbean and PO are separate, and they are unlikely to be the same. Actionformbean is a single corresponding to the form table inside the page, what elements are inside the form, and what attributes are inside the bean. and the PO and database table, so if the database table does not modify, then the PO will not be modified, if the page process and database table fields are inconsistent, then how can you use Actionformbean to replace the PO?

For example, the user registration page requires the user to register the basic information, so the HTML form contains the basic information attribute, so you need a actionformbean to one by one corresponding (note: one by one corresponds), each bean property corresponds to a text box or selection box or something.

And what about the user's persistent object? What is the obvious difference between his attributes and Actionformbean? He's going to have some actionformbean. Collection attributes, such as the user's permission attributes, user's group attributes, user's posts, and so on. It is also possible that there are 3 attributes in Actionformbean, the first name of the user, middle name, last name, and a name object attribute in my user's persistent object.

Assuming that my registration page originally provided you with the first name, then Actionformbean on this property, and later I want you to provide the full name, you have to change the Actionformbean, add two attributes. But this time the PO should not modify the drip, because the database has not changed.

So in a complete Java EE system, how should the reasonable design?

JSP (View)---> Action Form Bean (Module)---> Action (Control)

The action Form Bean is the data representation of the Web layer, which corresponds to the HTML page Form, as long as the operation process of the Web page changes, it should be modified accordingly, it should not be passed to the business layer and the persistence layer, otherwise, once the page is modified, The large area of code that has been implicated in the business and persistence layers is a disaster for the maintainability and scalability of the software, Actiont is his boundary, so far!

Action (Web control)---> Business Bean---> DAO---> ORM--->db

The PO is the business layer and the persistence layer of data, it flows between the business layer and the persistence layer, he should not and can not be passed to the Web layer view, and Actionservlet is his boundary, so far!

Then take a look at the process of the entire architecture:

When a user accesses a Web page through a browser, a page is submitted. So the action gets this formbean, he will read the Formbean attribute, then construct a PO object, then call the business layer Bean class, complete the registration operation, redirect to the success page. After the business layer bean receives the PO object, it invokes the DAO interface method to persist the persisted object.

When a user queries a member for information, he queries with the full name, and the action gets a usernameformbean that includes 3 attributes, first name, middle name, last name, The action then reads the 3 attributes of Usernameformbean, constructs the name object, invokes the business bean, passes the name object to the business bean, and queries.

The business Bean Gets the name (note: The name object is just a property of user) and then calls the DAO interface and returns a user's Po object, noting that this user is different from the Userformbean used in the Web layer, and he has many collection properties. The business bean then returns the user object to the action.

After the action gets user, the user's basic attributes are removed (the collection property is exempt if not required), constructs the Userformbean, then Userformbean request.setattribute (...) and redirects to the query results page.

The query page gets the Actionformbean in the request object and automatically calls the tag display.

Summarize:

A Form Bean is a web-layer data representation that he cannot be passed to the business layer; The PO is a persisted layer of data indicating that in certain circumstances, such as hibernate, he can replace VO in the business layer, but both PO and VO must be restricted to use within the business layer, The control that reaches the Web layer at most must not be spread to view.

The data transformation between the Form Bean and the PO is dropped in the action.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.