[Book follow] J2EE anti-Pattern

J2EE anti-Pattern→ Recommendations → new books

Pricing: 49.00 RMB | price: 39.20 RMB (off)

| Su Jin Guo, such as (US) Dade (dusydney B .)
Mechanical Industry Press | 7111177029 |-1-1 | start: Small 16
Version: 2006/01/01 | category: program design → comprehensive

I want to view the details of this book. I want to buy it.

Related Articles

Common Anti-pattern in J2EE applications
Anti-patterns)

There are some common faults and errors in J2EE applications. According to the popular saying, they are called anti-pattern. If you don't pay attention to it, we will also commit crimes on our own, so let's make a rough arrangement. One is Memo, which is also a reference for friends who need it:

 

1-No EJB, not J2EE

EJB has been widely criticized for its 2.1 Development today. It provides things we don't need in many cases, in addition, in many cases, once EJB is selected, there is no other way not to use those bulky features. However, many so-called examples give us the illusion that it is not a J2EE application without using EJB. Which of the following solutions is to use session fa? In Ade mode, Entity Bean uses BMP + Local interface, and then provides a layer of stateless Session Bean, using remote and local interfaces. In this design mode, I think most of them are helpless. Today, we can even see that we do not use EJB. Spring, which is so popular, provides practical and powerful evidence for developing J2EE projects without EJB.

 

2-excessive layering

The superficial view of the J2EE specification is that many "layers" are defined for us, and there are also many "Roles" with clear division of labor ", in addition, the J2EE blueprint application is divided into many "layers", so that everyone thinks that the J2EE application should be very multi-layer. In fact, it is not necessary to analyze the specific situation.

 

3-frequent round-trip calls

The seemingly simple nature of ejbs often ignores remote calls that may occur during use. For example, in order to update a record, each field is remotely set, the unnecessary overhead is greatly increased, so we realize that using DTO in a call is a recommended solution.

 

4-over-using stateful session beans

Generally, if a session bean instance is stateful, it only serves a fixed user. If it is stateless, it can be called by different users. This is a bit similar (just a bit similar) the difference between the static and non-static methods of a class. In practice, we should avoid using stateful session beans unless necessary. We can keep the status outside the Session Bean, such as the session object of the Web Container or our custom class, instead of relying entirely on the stateful Session Bean to help us.

 

5-excessive sessions

The Session Object of the Web container is a good thing, which is convenient and straightforward to use. This causes many of us to abuse it and put everything in it. There are two prominent problems: one is resource waste; the other is that in case of a Web server crash, data that originally needs to be persisted will be lost. We need to consider which data can use the request, which data needs to be persisted to the database, and so on. We cannot rely solely on the session.

 

6-universal servlet or universal JSP

J2EE provides us with a wide range of technical options for the web layer. servlet or JSP are only one of them, although it is very powerful, however, it should not be responsible for all the functions of MVC. In reality, Struts well regulates this problem: servlet is responsible for scheduling, special actions are responsible for processing logic, and JSP is used for display on the user interface. JSP and Servlet are essentially the same thing. They only deal with problems from different perspectives. They have their own strengths and complement each other.