Simple J2EE (4) Some Technical Selection suggestions

This article lists some problems that are frequently encountered during development and I hope to help you.

 

1. Data Verification

Obviously, normal J2EE programs cannot do without data verification. Data verification is divided into client verification and server verification. The advantage of client verification is that the user experience is good. After entering something, you can get a response immediately, without the need to connect to the Internet, and the pressure on the server is lower. However, client verification faces the challenge of cross-browser authentication. Upgrading the browser configuration will also cause problems to the application. Of course, a person with a little understanding of JS can easily skip client data verification. The data validation on the server is much more robust, but the overhead on the system is much higher. It's like buying a server. Of course IBM is good, but it's expensive! Someone suggested that the data validation should be placed on the server. He is really rich ......

Which side does the data verification work on or both sides? This needs to be selected based on the characteristics of the project, or even the importance of page data. Of course, a better way is not to perform data validation-data input methods such as selection boxes are used to restrict user input, and no data validation is required.

 

2. prevent repeated customer requests

Sometimes, users may accidentally submit data repeatedly, which may cause serious consequences in fields with high requirements for data submission, such as e-commerce. For example, if you submit an order twice, but you only want to buy one item ......

At this time, the best way to handle this is to explicitly refresh the session. Before the page processing is complete, update the session. In this way, the session is still available and the server can check the validity of the session.

 

3. Maintain session Status

Client technologies include: using hidden forms in HTML, using cookies, and URL rewriting.

1. Easy to hide forms. It is suitable for use in a project where the session status is not used in many cases. However, if the session technology requires a lot of projects, a large number of hidden forms will appear repeatedly on each page, which will bring negative efficiency. Second, because the hidden form is in plain text (you can view the page source code), if the session information is sensitive, encryption is even required.

2. Rewrite the URL. This method is useful in non-form submission. However, it cannot avoid hiding the defects of the form method.

3. Cookie technology: I personally reject this technology and I will not write it here.

In summary, the client maintains the session state, which is lightweight and unreliable.

Server-side session technology: httpsession. This is not a clear one or two sentence, and will be written in special articles later.

 

4. Functions of JSP

In the J2EE technology system, JSP is actually quite awkward. What it does is servlet can be done completely, while jsp can basically replace servlet. Currently, most programmers can use Servlet as a non-view layer, but many programmers cannot use JSP as a view. A good implementation should be that JSP is only used for display, but nothing else. The advantage is that the layers are reasonable and easy to maintain.

 

5. Use of CSS

CSS is a very efficient method to ensure the uniformity and efficiency of the program interface. Similar CSS concepts are also used in the so-called fourth-generation User Interface Android and iPhone UI.

 

6. EJB Design

We all know that EJB is used to process the business logic, but not everyone can grasp the EJB Design. For example, if a user submits a shopping request, the backend must first determine the user's credibility before deciding whether to generate an order. So should such functions be designed in an EJB? A good design principle is low coupling and high cohesion. If the credit rating and order functions are no longer used elsewhere, it is reasonable to write these steps in an EJB. However, if these two functions are also used elsewhere, it is reasonable to design three ejbs: one to complete credit judgment, the other to complete the order function, the other to complete the controller and the role of the coupler.

 

7. Data Interaction Between the EJB layer and the web layer

Many people take it for granted that the simple type is used when two layers of interactive information, a large amount of data, and a small amount of data are used. In fact, in highly concurrent enterprise applications, using object types to interact between the two layers can reduce network pressure and make data more correlated.

 

8. EJB Performance

Most J2EE applications have performance bottlenecks in the EJB layer, because the EJB layer may perform a lot of network communication, which seriously reduces the effect of the EJB layer, the best solution is to place the components and ejbs that need to frequently communicate with ejbs on a server.