12 most important J2EE best practices (1)

In order not to complicate the problem, we will use the most important 12 J2EE best practices ......

Best practices

1. Always use the MVC framework.
2. apply automatic unit testing and test management at each layer.
3. develop according to the specifications, rather than the application server.
4. Plan to use J2EE Security from the very beginning.
5. create what you know.
6. Always use session facades when using the EJB component.
7. Use stateless Session Bean instead of stateful Session Bean.
8. Use transactions managed by containers.
9. Use JSP as the first choice for presentation layer.
10. When using httpsession, try to only save the status required by the current firm, and do not store other content in httpsession.
11. Enable Dynamic Caching in WebSphere and use the WebSphere servlet caching mechanism.
12. To improve the efficiency of programmers, the CMP Entity Bean is the preferred solution for o/R ing.

1. Always use the MVC framework.
The MVC framework can clearly separate business logic (Java Beans and EJB components), controller logic (servlets/struts action), and presentation layer (JSP, XML/XSLT. Good layering can bring many benefits.

The MVC framework is so important for the successful use of J2EE that no other best practices can be compared with it. Model-View-controller (MVC) is the basis for designing J2EE applications. MVC divides your program code into the following parts:

Code responsible for business logic (that is, model-usually implemented using EJB or common Java objects ).

Code displayed on the user interface (that is, view-usually implemented through JSP and tag library, and sometimes implemented using XML and XSLT ).

Code responsible For the application process (that is, the Controller-usually implemented using Java Servlet or a class like struts Controller ).

If you do not follow the basic MVC framework, many problems may occur during the development process. The most common problem is that too many components are added to the view. For example, JSP tags may be used to perform database access or process control of applications in JSP, this is common in small-scale applications. However, with the development in the future, this will cause problems because JSP is becoming increasingly difficult to maintain and debug.

Similarly, we often see that the view layer is built into the business logic. For example, a common problem is to directly apply the XML parsing technology used when building a View to the business layer. The business layer should operate on the business object, rather than the specific data representation bound to the view.

However, having the right components does not necessarily mean that your applications can be well layered. We often see that some applications include servlet, JSP, and EJB components. However, the main business logic is implemented at the servlet layer, or the application navigation is processed in JSP. You must perform a strict code check and refactor your code to ensure that the business logic of the application is only processed at the model layer, the application navigation only uses the Controller layer for processing, and your views only represent the passed Model Objects in HTML and JavaScript format.

2. Use automated unit testing and test management at each layer of the application.
Do not just test your GUI ). Stratified testing makes testing and maintenance extremely simple.

Over the past few years, there have been considerable innovations in the methodology field, such as the emergence of agile (for example, scrum [schwaber] and extreme programming [beck1]). the lightweight method is now widely used. One common feature of almost all of these methods is that they advocate the use of automated testing tools that can help developers perform regression testing (regression testing) in less time ), it can also help them avoid errors caused by inadequate regression testing, so it can be used to improve the efficiency of programmers. In fact, there is also a method called test-first development [beck2], which even advocates writing unit tests before developing actual code. However, before you test the code, you need to split the code into some testable parts. A "big mud ball" is hard to test because it is not just a simple and easy-to-recognize function. If each piece of your code implements multiple functions, it is difficult to ensure full correctness of such code.

One advantage of the MVC framework (as well as the MVC implementation in J2EE) Is that componentized elements can (in fact, quite simple) Perform unit tests on your applications. Therefore, you can easily write test cases for entity beans, session beans, and JSP without having to consider other code. There are many frameworks and tools for J2EE testing, which make the process easier. For example, JUnit (an open source code tool developed by junit.org) and cactus (an open source code tool developed by Apache) are useful for testing J2EE components. [Hightower] discusses in detail how to use these tools in J2EE.

Although all this details how to thoroughly test your application, we still see some people think that as long as they test the GUI (possibly web-based GUI, or independent Java applications), then they fully test the entire application. Gui testing is difficult to achieve comprehensive testing for the following reasons. First of all, it is difficult to thoroughly test every path of the system using GUI testing. GUI is only a method that affects the system. There may be background operations, scripts, and various other access points, this also requires testing. However, they generally do not have a GUI. Second, Gui-level testing is a very coarse-grained test. This test is only performed to test the system at the macro level. This means that once a problem is found, the entire subsystem associated with the problem should be checked, which makes it very difficult to identify the bug (defect. Third, Gui testing can be well tested only after the entire development cycle. This is because the GUI is fully defined at that time. This means that potential bugs can only be found later. Fourth, General developers may not have automated GUI testing tools. Therefore, when a developer changes the Code, there is no simple way to re-test the affected subsystem. This is not conducive to good testing. If developers have automated code-level unit testing tools, they can easily run these tools to ensure that changes do not disrupt existing features. Finally, if the Automatic Build function is added, it is very easy to add an automatic unit test tool during the Automatic Build Process. After completing these settings, the entire system can be reconstructed regularly, and regression testing almost requires no human involvement.

In addition, we must emphasize that using EJB and Web Services for distributed and component-based development makes it necessary to test a single component. If there is no "Gui" to be tested, you must perform a low-level test. It is best to start testing in this way, saving you the trouble to re-test distributed components or web services as part of your applications.

In short, automatic unit testing can quickly detect system defects and make it easy to detect these defects, making the testing work more systematic and thus improving the overall quality.

3. develop according to the specifications, rather than the application server.
It is necessary to keep the norms in mind. If you want to deviate from them, you must carefully consider them before doing so. This is because when you deviate from the rules, what you do is often not what you should do.

When you want to deviate from what J2EE allows you to do, this can easily cause your misfortune. We found that some developers studied some things that J2EE allowed, and they thought this could improve the performance of J2EE slightly, in the end, they will only find that this will cause serious performance problems, or be transplanted in the future (from one vendor to another, or more commonly from one version to another). In fact, this porting problem is so serious that [Beaton] calls this principle a basic best practice for porting.

There are several issues if you do not directly use the methods provided by J2EE. A common example is that developers use the JAAS module to replace J2EE Security, instead of using the built-in compliant application server mechanism for verification and authorization. Be sure not to leave the verification mechanism provided by the J2EE specification. If you leave this specification, this will be the main cause of system security vulnerabilities and vendor compatibility problems. Similarly, you need to use the authorization mechanism provided by the servlet and EJB specifications, and if you want to deviate from these specifications, make sure that you use the APIS defined by the specifications (such as getcallerprincipal ()) as the basis for implementation. In this way, you will be able to take advantage of the strong security infrastructure provided by the vendor, where business requirements need to support complex authorization rules.

Other common problems include the use of persistence mechanisms that do not comply with J2EE specifications (which makes transaction management difficult) and the use of inappropriate j2se methods (such as threads or Singleton) in J2EE programs ), and use your own methods to resolve the program-to-program communication, rather than using the mechanisms supported internally by J2EE (such as JCA, JMS, or web services ). When you port a J2EE-compliant server to another server or a new version of the same server, the above design will cause numerous problems. The only deviation from a specification is that a problem cannot be solved within the scope of the Specification. For example, the business logic scheduled for execution is a problem before ejb2.1 occurs. In such a case, we recommend that you use the solution provided by the vendor (such as the scheduler tool in WebSphere Application Server Enterprise) when there is a solution provided by the vendor ), third-party tools are used when no solutions are provided by the vendor. If you use the solution provided by the vendor, application maintenance and porting it to a new standard version will be a vendor issue, not your issue.

Finally, be sure not to use the new technology too early. Too keen on adopting technologies that have not yet been integrated into the J2EE specification or that have not yet been integrated into the vendor's products will often have disastrous consequences. Support is critical-if your vendor does not directly support a specific technology proposed in JSR, but this technology is not accepted by J2EE, you should not use this technology. After all, most of us are engaged in solving business problems, rather than promoting technological development.