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

This article mainly explains "what is the method of data representation in J2EE architecture". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the method of data representation in J2EE architecture".

In the structure of struts+ hibernate, the PO generated by Hibernate should not be passed directly to JSP, whether it is Iterator or List, which is a design error.

Let me talk about the data representation of the various layers in the J2EE architecture:

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

The data representation of the business layer is VO

The data representation of the persistence layer is PO, whose data comes from the database, and the data representation of the persistence layer, such as CMP.

In a standard J2EE architecture, the data representation of different layers should be limited within 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 J2EE architecture as a whole. For example, if the logic of the FormBean layer has been modified, only the structure of the Web layer needs to be modified, not the code changes that touch the business layer and persistence layer. Similarly, when the database table makes small adjustments, only the persistence layer data representation needs to be modified, without touching the business layer code and the Web layer code.

However, because the powerful functions of Hibernate, such as the state management of dynamically generating PO,PO, can be separated from Session, PO can completely act as VO in the J2EE framework where Hibernate is applied, so let's merge PO and VO, collectively called PO.

Let's start with the big difference between ActionFormBean and PO in the persistence layer.

In simple applications, there is almost no difference between ActionFormBean and PO, so many people simply use ActionFormBean as PO, so ActionFormBean goes from the JSP page to the Servlet control layer to the business layer, and then through the persistence layer, * all the way to the database table. What a stick to the bottom!

But in complex applications, ActionFormBean and PO are separate, and they can't be the same. ActionFormBean corresponds to the Form form in the web page one by one. Whatever elements are in the Form, there are attributes in the Bean. The PO corresponds to the database table, so if the database table is not modified, the PO will not be modified, and if the page flow is inconsistent with the database table field, how can you use ActionFormBean instead of PO?

For example, the user registration page requires the basic information of the registered user, so the HTML Form contains basic information attributes, so you need an ActionFormBean to correspond one to one (note: one to one), each Bean property corresponds to a text box or a selection box or something.

And what about the persistent object of the user? What is the obvious difference between his attributes and ActionFormBean? It will have some collection attributes that ActionFormBean does not have, such as user permissions, user group attributes, user posts, and so on. It is also possible that there are three properties in ActionFormBean, namely, the user's First Name, Middle Name, and Last Name, and in my User persistent object is a Name object property.

Suppose my registration page originally as long as you provide First Name, then ActionFormBean on this one attribute, later I want you to provide the full name, you want to change ActionFormBean, add two attributes. But PO should not be modified at this time, because the database has not changed.

So how to make a reasonable design in a complete J2EE system?

JSP (View)-- > ActionFormBean (Module)-> Action (Control)

ActionFormBean is the data representation of the Web layer, which corresponds to the Form of the HTML page. As long as the operation flow of the Web page changes, it should not and cannot be passed to the business layer and persistence layer, otherwise, once the page is modified, it will always involve a large area of code in the business layer and persistence layer for modification, which is a disaster for the maintainability and expansibility of the software. Actiont is its boundary. That's it!

Action (Web Control)-> Business Bean-> DAO-> ORM-- > DB

PO is the data representation of business layer and persistence layer, it flows between business layer and persistence layer, it should not and cannot be passed to the View of Web layer, and ActionServlet is his boundary, that's it!

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

When a user visits a web page through a browser, a page is submitted. So Action gets the FormBean, reads out the FormBean attribute, constructs a PO object, calls the Bean class of the business layer, completes the registration, and redirects to the success page. After receiving the PO object, the business layer Bean calls the DAO interface method to persist the persistent object.

When a user queries the information of a member, he queries with his full name, so Action gets a UserNameFormBean that includes three attributes, namely first name, middle name, and last name. Then Action reads out the three attributes of UserNameFormBean, constructs the Name object, calls the business Bean, and passes the Name object to the business Bean for query.

The business Bean gets the Name (note: the Name object is only a property of User) and then calls the DAO API to return a PO object of User. Note that this User is different from the UserFormBean used in the Web layer, it has many collection properties. The business Bean then returns the User object to Action.

After Action gets the User, take out the basic properties of the User (not if the collection properties are not needed), construct the UserFormBean, then UserFormBean request.setAttribute (...), and then redirect to the query results page.

The query page gets the ActionFormBean in the request object and automatically calls tag to display it.

Summary:

FormBean is the data representation of the Web layer, and it cannot be passed to the business layer; PO is the data representation of the persistence layer. Under certain circumstances, such as Hibernate, it can replace VO to appear in the business layer, but both PO and VO must be limited to the business layer. Control that reaches the Web layer at most must not be spread to the View.

The data conversion between FormBean and PO is done in Action.

BTW:

JDO1.x is not as powerful as Hibernate, and PO cannot be separated from the persistence layer, so VO must be used in the business layer, so a large number of conversion operations of VO and PO must be carried out in the business layer. Compared with Hibernate, programming is more cumbersome.

Of course, theory is one thing, and you don't have to do it in practice. You can make your own choice, be flexible in the actual project, add a little bad smell, and improve development efficiency. It's just that in large-scale projects, it is still a perfect fit, otherwise, it will be very painful to change the version.

Thank you for your reading, the above is the content of "what is the method of data representation of J2EE architecture". After the study of this article, I believe you have a deeper understanding of what the method of data representation of J2EE architecture is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.