12 most important J2EE best practices (1)

12 most important J2EE best practices (1) -- Linux general technology-Linux programming and kernel information. The following is a detailed description. 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 (I .e. model ?? It is usually implemented using ejbs or common Java objects ).
? Code displayed on the user interface (view ?? It is usually implemented through JSP and tag library, and sometimes it is implemented using XML and XSLT ).
? Code responsible For the application process (that is, the controller ?? It is 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. What is the Business Object of the business layer ?? Instead of binding a specific data representation 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 "slightly" improve J2EE performance, 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. Is support 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.

4. Plan to use J2EE Security from the very beginning.

Enable WebSphere security. This allows your EJB and URL to at least allow access by all authorized users. Don't ask why ?? Just follow the instructions.

There were very few customers who planned to enable WebSphere J2EE Security from the very beginning, and we were surprised by the 1.1 straight forward. It is estimated that only about 50% of customers plan to use this feature from the very beginning. For example, we have worked with some large financial institutions (banks, agents, and so on) and they do not intend to enable security. Fortunately, this problem can be solved during pre-deployment checks.

It is dangerous not to use J2EE Security. Assuming that your applications require security (almost all applications need it), you can bet that your developers can build their own security system, this system is better than the one you bought from the J2EE manufacturer. This is not a good bet. It is extremely difficult to provide security for distributed applications. For example, you need to use a network security encryption token to control access to ejbs. In our experience, most self-built security systems are insecure and have major defects, which makes the product system extremely vulnerable.

Some reasons for not using J2EE Security include: worry about performance degradation, believe that other security (such as Netegrity SiteMinder) can replace J2EE Security, or do not know the security features and functions of WebSphere Application Server. Do not fall into these traps. Especially, although products such as Netegrity SiteMinder provide excellent security features, they alone cannot protect the entire J2EE application. These products must be combined with J2EE application servers to fully protect your system.

Another common reason for not using J2EE Security is that the role-based model does not provide adequate granularity access control to meet complex business rules. Despite the fact, this should not be the reason for not using J2EE Security. On the contrary, J2EE authentication and J2EE roles should be combined with specific extension rules. If a complex business rule requires a security decision, write the corresponding code. The security decision should be based on the usable and reliable J2EE authentication information (user ID and role ).

5. create what you know.

Repeated development work will allow you to gradually master all the J2EE modules. All modules should be involved from the very beginning rather than from the very beginning.

We must acknowledge that J2EE is a huge system. If a development team only begins to use J2EE, it will be difficult to grasp it at once. There are too many concepts and APIs to be mastered in J2EE. In this case, the key to successfully master J2EE is to start with a simple step.

This method can be best implemented by creating small and simple modules in your application. If a development team creates a simple domain model and a backend persistence mechanism (probably using JDBC) and performs a complete test on it, this will enhance their self-confidence, so they will use this domain model to master front-end development using servlet and JSP. If an development team finds it necessary to use EJB, they will similarly start to use simple session Facades on the persistent EJB component of container management, you can also use JDBC-based Data Access Objects and DAO instead of skipping them to use more complex structures (such as message-driven bean and JMS ).

This method is not a new method, but few developers use it to develop their skills. On the contrary, most development teams try to build all the modules right away, involving both the view layer, model layer, and controller layer in MVC, the result is that they are often under pressure of progress. They should consider some Agile development methods, such as extreme programming (XP), which adopt an incremental learning and development method. In XP, there is a process called ModelFirst, which involves first building a domain model as a mechanism to organize and implement user scenarios. Basically, you need to build a domain model as the first part of the user scenario you want to implement, and then build a user interface (UI) on top of the domain model as the result of user scenario implementation. This method is very suitable for an developer to learn only one technology at a time, rather than asking them to face many situations at the same time (or asking them to read a lot of books), which will cause them to crash.

Also, repeated development at each application layer may contain some appropriate patterns and best practices. If you start to apply some modes such as data access objects and session Facades from the underlying layer of the application, you should not use the domain logic in your JSP and other view objects.

Finally, when you develop some simple modules, you can test the performance of your applications at the beginning. If you do not perform performance tests until the end of application development, this will often have disastrous consequences.