《二手车销售系统外文翻译(范文).doc》由会员分享，可在线阅读，更多相关《二手车销售系统外文翻译(范文).doc（16页珍藏版）》请在三一办公上搜索。
1、 外文文献资料（外文文件名：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 re
2、sources, 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. Unf
3、ortunately, 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 auto
4、mated 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 se
5、ssion 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 serv
6、let 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).
7、 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 f
8、ollowing 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.
9、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
10、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 per
11、forming 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 instan
12、ce, 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 applicati
13、on 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
14、 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
15、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 R
16、esources) 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 tes
17、ting. In fact, a practice called Test-First Development Beck2 takes this practice even further by advocating that unit tests be written prior to the development of the actual code itself. However, before you can test your code, you need to isolate it into testable fragments. A big ball of mud is har
18、d to test because it does not do a single, easily identifiable function. If each segment of your code does several things, it is hard to test each bit for correctness.One of the advantages of the MVC architecture (and the J2EE implementation of MVC) is that the componentization of the elements make
19、it possible (in fact, relatively easy) to test your application in pieces. Therefore, you can easily write tests to separately test Entity beans, Session beans, and JSPs outside of the rest of the code base. There are a number of frameworks and tools for J2EE testing that make this process easier. F
20、or instance, JUnit, which is an open-source tool developed by junit.org, and Cactus, which is an open source project of the Apache consortium, are both quite useful for testing J2EE components. Hightower discusses the use of these tools for J2EE in detail. Despite all of the great information about
21、deeply testing your application, we still see many projects that believe that if they test the GUI (which may be a Web based GUI or a standalone Java application), then they have comprehensively tested the entire application. GUI testing is rarely enough. There are several reasons for this. First, w
22、ith GUI testing, it is difficult to test every path through the system. The GUI is only one way of affecting the system. There may be background jobs, scripts, and various other access points that also need to be tested. Often, however, they do not have GUIs. Secondly, testing at the GUI level is ve
23、ry coarse grained. It tests at the macro level of the system how the system behaves. This means that if problems are found, entire subsystems must be considered, making finding the bugs identified difficult. Third, GUI testing usually cannot be done well until late in the development cycle when the
24、GUI is fully defined. This means that latent bugs will not be found systematically until very late. Fourth, average developers probably do not have access to automatic GUI testing tools. Thus, when a developer makes a change, there is no easy way for that developer to retest the affected subsystem.
25、This actually discourages good testing. If the developer has access to automated code level unit tests, the developer can easily run them to make sure the changes do not break existing function. Finally, if automated builds are done, it is fairly easy to add an automated unit testing suite to the au
26、tomated build process. By doing this, the system can be rebuilt regularly (often nightly) and regression-tested with little human intervention. In addition, we must emphasize that distributed, component based development with EJBs and Web services makes testing your individual components absolutely
27、necessary. When there is no GUI to test, you must then fall back on lower-level tests. It is best to start that way, and spare yourself the headache of having to retrofit your process to include those tests when the time comes to expose part of your application as a distributed component or Web serv
28、ice.In summary, by using automated unit tests, defects are found sooner, defects are easier to find, testing can be made more systematic, and thus, overall quality is improved. 3. Develop to the specifications, not the application serverKnow the specifications by heart and deviate from them only aft
29、er careful consideration. Just because you can do something doesnt mean you should. It is very easy to cause yourself grief by trying to play around at the edges of what J2EE allows you to do. We find developers dig themselves into a hole by trying something that they think will work a little better
30、 than what J2EE allows, only to find that it causes serious problems in performance, or in migration (from vendor to vendor, or more commonly from version to version) later. In fact, this is such an issue with migrations, that Beaton calls this principle out as the primary best practice for Migratio
31、n efforts. There are several places in which not taking the most straightforward approach can definitely cause problems. A common one today is where developers take over J2EE security through the use of JAAS modules rather than relying on built-in spec compliant application server mechanisms for aut
32、hentication and authorization. Be very wary of going beyond the authentication mechanisms provided by the J2EE specification. This can be a major source of security holes and vendor compatibility problems. Likewise, rely on the authorization mechanisms provided by the servlet and EJB specs, and wher
33、e you need to go beyond them, make sure you use the specs APIs (such as getCallerPrincipal() as the basis for your implementation. This way you will be able to leverage the vendor-provided strong security infrastructure and, where business needs require, support more complex authorization rules.Othe
34、r common problems include using persistence mechanisms that are not tied into the J2EE spec (making transaction management difficult), relying on inappropriate J2SE facilities like threading or singletons within your J2EE programs, and rolling your own solutions for program-to-program communication
35、instead of staying within supported mechanisms like JCA, JMS, or Web services. Such design choices cause no end of difficulty when moving from one J2EE compliant server to another, or even when moving to new versions of the same server. Using elements outside of J2EE often causes subtle portability
36、problems. The only time you should ever deviate from a spec is when there is a clear problem that cannot be addressed within the spec. For instance, scheduling the execution of timed business logic was a problem prior to the introduction of EJB 2.1. In cases like this, we may recommend using vendor-
37、provided solutions where available (such as the Scheduler facility in WebSphere? Application Server Enterprise), or to use third-party tools where these are not available. In this way, maintenance and migration to later spec versions becomes the problem of the vendor, and not your own problem.Finall
38、y, be careful about adopting new technologies too early. Overzealously adopting a technology before it has been integrated into the rest of the J2EE specification, or into a vendors product, is often a recipe for disaster. Support is critical - if your vendor does not directly support a particular t
39、echnology proposed in a JSR but not yet accepted into J2EE, you should probably not pursue it. After all, with rare exceptions, most of us are in the business of solving business problems, not advancing technology for the sheer fun of it.4. Plan for using J2EE security from Day One Turn on WebSphere
40、 security. Lock down all your EJBs and URLs to at least all authenticated users. Dont even ask - just do it.It is a continual source of astonishment to us how few customers we work with originally plan to turn on WebSpheres J2EE security. In our estimate around 50% of the customers we see initially
41、plan to use this feature. For instance, we have worked with several major financial institutions (banks, brokerages, and so on) that did not plan on turning security on; luckily this problem was fixed in review prior to deployment.Not leveraging J2EE security is a dangerous game. Assuming your appli
42、cation requires security (almost all do), you are betting that your developers can build a better security infrastructure than the one you bought from the J2EE vendor. Thats not a good bet. Securing a distributed application is extraordinarily difficult. For example, you need to control access to EJ
43、Bs using a network safe encrypted token. In our experience, most home-grown security infrastructures are not secure; with significant weaknesses that leave production systems terribly vulnerable. (Refer to chapter 18 of Barcia for more.)Reasons cited for not using J2EE security include: fear of perf
44、ormance degradation, belief that other security products like Netegrity SiteMinder handle this, or ignorance of the features and capabilities of WebSphere Application Server security. Do not fall into these traps. In particular, while products like SiteMinder provide excellent security features, the
45、y alone cannot secure an entire J2EE application. They must work hand in hand with the J2EE application server to secure all aspects of the system.Another common reason given for not using J2EE security is that the role-based model does not provide sufficiently granular access control to meet comple
46、x business rules. Though this is often true, this is not a reason to avoid J2EE security. Instead, leverage the J2EE authentication model and J2EE roles in conjunction with your specific extended rules. If a complex business rule is needed to make a security decision, write the code to do it, basing
47、 the decision upon the readily available and trustable J2EE authentication information (the users ID and roles).5. Build what you knowIterative development allows you to gradually master all the moving pieces of J2EE. Build small, vertical slices through your application rather than doing everything
48、 at once.Lets face it, J2EE is big. If a development team is just starting with J2EE, it is far too difficult to try to learn it all at once. There are simply too many concepts and APIs to master. The key to success in this environment is to take J2EE on in small, controlled steps.This approach is b
49、est implemented through building small, vertical slices through your application. Once a team has built its confidence by building a simple domain model and back-end persistence mechanism (perhaps using JDBC) and thoroughly tested that model, they can then move on to mastering front-end development with servlets and JSPs that use that domain model. If a development team finds a need for EJBs, they could likewise start with simple Ses
