In order not to complicate problems, we use-the most important 12 J2EE best practice ... Best practice 1, always use the MVC framework. 2, automatic unit testing and test management is applied at each layer. 3. Develop according to the specification, rather than in accordance with the application server. 4. Plan J2EE security from the beginning. 5. Create what you know. 6. Always use session facades when using EJB components. 7. Use stateless session beans instead of state session bean. 8, using container management transactions. 9. JSP as the preferred layer of the representation. 10. When using the HttpSession, try to save the status required by the current transaction, and other content should not be saved in httpsession. 11. In WebSphere, start the dynamic cache and use the WebSphere Servlet cache mechanism. 12. In order to improve the work efficiency of programmers, CMP entity beans are the preferred solution for O / R mapping. 1. Always use the MVC framework. The MVC framework can clearly separate business logic, controller logic (servlets / struts), representation layer (JSP, XML / XSLT). Good layers can bring a lot of benefits. The MVC framework is so important for successful use J2EE, so that there is no other best practice to compare with it. Model - View-Controller (MVC) is the basis for designing J2EE applications. MVC simply divides the following sections to: responsible for business logic code (ie, model-usually implemented using EJB or normal Java objects). Responsible for the code displayed by the user interface (ie view-usually implemented through the JSP and tag library, sometimes using XML and XSLT). The code responsible for the application process (ie, the controller - usually uses the Java Servlet or class like the Struts controller). If you don't follow the basic MVC framework, there will be a lot of questions during the development process. The most common problem is to add too much ingredients to the view section, for example, there may be use JSP tags to perform database access, or perform flow control in JSP, which is more common in small-scale applications. However, with later development, this will bring problems because JSP will gradually become more difficult to maintain and debug. Similarly, we have often seen the case where the view layer is built to business logic. For example, a common problem is to apply directly to the business layer when the XML parsing technique used in building a view. The business layer should operate on the business object - rather than the specific data indicating that binds to the view. However, it is only a suitable component that does not necessarily mean that your application can get a suitable hierarchy. We often see all three applications containing all three items, JSP, and EJB components, however, its main business logic is implemented in the servlet layer, or application navigation is processed in JSP. You must make a strict code check and reconstruct your code to ensure that the application's business logic is processed by the Model Layer. The application navigation is only processed by the controller layer. Views (Views) just expressed the passing model objects in HTML and JavaScript. 2. Automatic unit testing and test management are used in each layer of the application. Don't just test your graphical user interface (GUI). The layered test makes testing and maintenance work extremely simple.
In the past few years, there is a considerable innovation in the field of methodology, such as the newly known as agile (such as Scrum [Schwaber] and Extreme Programming [BECK1]), it has been very common. Applications. One common feature in almost all of these methods is that they all advocate automatic test tools that help developers regress Testing with less time and help them avoid inadequate regression. The test caused by the test can therefore be used to improve programmers' work efficiency. In fact, there is also a method called Test-First Development [beck2], which even has a first write unit test before developing the actual code. However, before you test the code, you need to split the code into some tested pieces. A "big mud ball" is difficult to test because it is not only a simple and easy-to-identification function. If you implement multiple functions, such code will be difficult to ensure its complete correctness. One advantage of the MVC framework (and the MVC implementation in J2EE) is that the componentization of the element (actually, quite simple) makes cell testing for your application. Therefore, you can easily write test cases independently of entity beans, session beans, and JSP without having to consider other code. There are now many frameworks and tools for J2EE testing, which make this process easier. For example, JUnit is useful to test J2EE components for test J2EE components by JUnit (open source tool developed by junit.org) and CACTUS. [Hightower] explores how to use these tools in J2EE in J2EE. Although all of these details how thoroughly test your app, we still see some people think that as long as they test the GUI (may be web-based GUI, or independent Java applications), they are comprehensive Tested the entire application. The GUI test is difficult to achieve comprehensive testing, with the following reasons. First, use the GUI test to completely test each path of the system, and GUI is only a way of impacting the system, there may be background operations, scripts, and various other access points, which also requires testing. However, they usually do not have a GUI. Second, the test of the GUI is a very coarse particle size test. This test is only the behavior of the test system on a macro level. This means that once there is a problem, the entire subsystem related to this problem is checked, which makes it very difficult to find Bug (defect). Third, GUI test usually only tests well in the later period of the development cycle, because only this time GUI gets a complete definition. This means that only potential bugs can only be found in later periods. Fourth, a general developer may have no automatic GUI test tool. Therefore, when a developer changes the code, there is no simple method to retest the affected subsystem. This is actually unfavorable to conduct a good test. If the developer has an automatic code-level unit test tool, developers can easily run these tools to ensure that changes made will not destroy the existing features. Finally, if an automatic build feature is added, it is very easy to add an automated unit test tool during the automatic building. When these settings are completed, the entire system can be regularly reconstructed, and the regression test is hardly involved. In addition, we must emphasize that the use of EJB and Web services, component-based development makes testing a single component becomes very necessary.
If you don't have a "GUI" to test, you must perform a low-level test. It is best to start testing in this way, save the distributed component or web service as part of your application, you have to spend your efforts to tested. In summary, by using an automated unit test, the system's defects can be quickly discovered, and these defects are also easily discovered, making the testing work more systematically, so the overall quality is also improved. 3. Developments in accordance with the specification, rather than in accordance with the application server. To be familiar with the specification, if you want to deviate from the specification, you can do this after careful consideration. This is because when you deviate from the rules, what you do is often not what you should do. This is easy for you to make you unfortunate when you want to take the J2EE. We have found that there are some developers to study something other than J2EE allowed, they think so can "slightly" improve J2EE performance, and they will eventually find that this will cause serious performance issues, or in the future transplant (from A vendor will have problems in another vendor, or more common from a version to another. In fact, this transplant problem is so serious, so that [Beaton] refers to this principle as the basic best practice of transplantation. Now there are several places if they don't directly use J2EE, will definitely produce problems. A common example is that developers replace J2EE security by using JAAS modules, rather than using built-in compliance with the specific scheduled application server mechanism. Be careful not to be separated from the authentication mechanism provided by the J2EE specification. If this specification is separated, this will be the main reason for the system has security vulnerabilities and vendor compatibility issues. Similarly, you should use the authorization mechanism provided by the servlet and the EJB specification, and if you want to deviate from these specifications, make sure to use the specification defined API (such as getCallerPrincipal ()) as the foundation of the implementation. In this way, you will be able to use the strong security infrastructure provided by the manufacturer, where business requirements need to support complex authorization rules. Other common problems include using a persistence mechanism that does not follow J2EE specifications (this makes transaction management difficult), using inappropriate J2SE methods (such as thread or singleton) in the J2EE program, and use your own method to resolve procedures Program-to-program communication, rather than using J2EE's inner support (eg JCA, JMS, or web services). The above design selection will cause numerous problems on the new version of the server that follows J2EE to other servers or ported to the same server. The only thing to depart from the specification is that when a problem is unable to solve in the specification. For example, the operational logic of schedules perform timing is a problem before EJB2.1 appears. In case of this, we recommend using the solution provided by the manufacturer when there is a solution provided by the manufacturer (such as the WebSphere Application Server Enterprise in WebSphere Application Server Enterprise). Scheduler tools, while using the tools provided by third parties when there is no vendor. If you use the solutions provided by the manufacturer, the application's maintenance and the transplantation to the new specification version will be the manufacturer's question, not your problem. Finally, be careful not to use new technologies too early. It is too keen to use other parts that have not been integrated into the J2EE specification or the techniques that have not been integrated into the vendor's products often bring catastrophic consequences.
