外文文献资料（外文文件名： The top Java EE best practices）IntroductionOver the last five years, a lot has been written about J2EE best practices. There now are probably 10 or more books, along with dozens of articles that provide insight into how J2EE applications should be written. In fact, there are so many resources, often with contradictory recommendations, navigating the maze has become an obstacle to adopting J2EE itself. To provide some simple guidance for customers entering this maze, we set out to compile the following top 10 list of what we feel are the most important best practices for J2EE. Unfortunately, 10 was not enough to capture everything that needed to be said, especially when you consider Web services development as a part of J2EE. Thus, in honor of the growth of J2EE, we have decided to make our top 10 list a top 12 list instead. The best practices1. Always use MVC. 2. Apply automated unit tests and test harnesses at every layer. 3. Develop to the specifications, not the application server. 4. Plan for using J2EE security from Day One. 5. Build what you know. 6. Always use Session Facades whenever you use EJB components. 7. Use stateless session beans instead of stateful session beans. 8. Use container-managed transactions. 9. Prefer JSPs as your first choice of presentation technology. 10. When using HttpSessions, store only as much state as you need for the current business transaction and no more. 11. In WebSphere, turn on dynamic caching and use the WebSphere servlet caching mechanism. 12. Prefer CMP Entity beans as a first-pass solution for O/R mapping due to the programmer productivity benefits. 1. Always use MVCCleanly separate Business Logic (Java beans and EJB components) from Controller Logic (Servlets/Struts actions) from Presentation (JSP, XML/XSLT). Good layering can cover a multitude of sins.This practice is so central to the successful adoption of J2EE that there is no competition for the #1 slot. Model-View-Controller (MVC) is fundamental to the design of good J2EE applications. It is simply the division of labor of your programs into the following parts: a. Those responsible for business logic (the Model - often implemented using Enterprise Java?Beans or plain old Java objects). b. Those responsible for presentation of the user interface (the View - usually implemented with JSP and tag libraries, but sometimes with XML and XSLT). c. Those responsible for application navigation (the Controller - usually implemented with Java Servlets or associated classes like Struts controllers). There are a number of excellent reviews of this topic with regard to J2EE; in particular, we direct interested readers to either Fowler or Brown (see Resources) for comprehensive, in-depth coverage.There are a number of problems that can emerge from not following basic MVC architecture. The most problems occur from putting too much into the View portion of the architecture. Practices like using JSP tag libraries to perform database access, or performing application flow control within a JSP are relatively common in small-scale applications, but these can cause issues in later development as JSPs become progressively more difficult to maintain and debug.Likewise, we often see migration of view layer constructs into business logic. For instance, a common problem is to push XML parsing technologies used in the construction of views into the business layer. The business layer should operate on business objects - not on a particular data representation tied to the view.However, just having the proper components does not make your application properly layered. It is quite common to find applications that have all three of servlets, JSPs, and EJB components, where the majority of the business logic is done in the servlet layer, or where application navigation is handled in the JSP. You must be rigorous about code review and refactoring to ensure that business logic is handled in the Model layer only, that application navigation is solely the province of the Controller layer, and that your Views are simply concerned with rendering model objects into appropriate HTML and Javascript. 2. Apply automated unit tests and test harnesses at every layerDont just test your GUI. Layered testing makes debugging and maintenance vastly simpler.There has been quite a shake-up in the methodology world over the past several years as new, lightweight methods that call themselves Agile (such as SCRUM Schwaber and Extreme Programming Beck1 in Resources) become more commonplace. One of the hallmarks of nearly all of these methods is that they advocate the use of automated testing tools to improve programmer productivity by helping developers spend less time regression testing, and to help them avoid bugs caused by inadequate regression testing. In fact, a practice called Test-First Development Beck2 takes this practice even further by advocating that unit tests be written prior to the developmen