外文文献资料

（外文文件名：The top Java EE best practices）

Introduction

Over 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 practices

1. 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 MVC

Cleanly 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 layer

Don't 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 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 hard 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 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. For 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 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, with 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 very 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 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. 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 automated 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 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

service.

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 server

Know the specifications by heart and deviate from them only after careful consideration. Just because you can do something doesn't 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" 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 Migration 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 authentication 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 where you need to go beyond them, make sure you use the spec's 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.

Other 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 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 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-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.

Finally, 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 vendor's product, is often a recipe for disaster. Support is critical -- if your vendor does not directly support a particular technology 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 security. Lock down all your EJBs and URLs to at least all authenticated users. Don't 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 WebSphere's J2EE security. In our estimate around 50% of the customers we see initially 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 application 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. That's not a good bet. Securing a distributed application is extraordinarily

difficult. For example, you need to control access to EJBs 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 performance 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, they 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 complex 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 the decision upon the readily available and trustable J2EE authentication information (the user's ID and roles).

5. Build what you know

Iterative development allows you to gradually master all the moving pieces of J2EE. Build small, vertical slices through your application rather than doing everything at once.

Let's 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 best 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 Session Facades atop Container-Managed persistence EJB components or JDBC-based Data Access Objects (DAOs) before moving on to more sophisticated constructs like Message-Driven beans and JMS.

This approach is nothing new, but relatively few teams actually build their skills in this way. Instead, most teams cave in to schedule pressures by trying to build everything at once -- they attack the View layer, the Model Layer, and the Controller layer in MVC, simultaneously. Instead, consider some of the new Agile development methods, such as Extreme Programming (XP), that foster this kind of incremental learning and development. There is a procedure often used in XP called ModelFirst [Wiki] that involves building the domain model first as a mechanism for organizing and implementing your User Stories. Basically, you build the domain model as part of the first set of User Stories you implement, and then build a UI on top of it as a result of implementing later User Stories. This fits very well with letting a team learn technologies one at a time, as opposed to sending them to a dozen simultaneous classes (or letting them read a dozen books), which can be overwhelming.

Also, iterative development of each application layer fosters the application of appropriate patterns and best practices. If you begin with the lower layers of your application and apply patterns like Data Access Objects and Session Facades, you should not end up with domain logic in your JSPs and other View objects.

Finally, when you do development in thin vertical slices, it makes it easier to start early in performance testing your application. Delaying performance testing until the end of an application development cycle is a sure recipe for disaster, as

[Joines] relates.

6. Always use Session Facades whenever you use EJB components

Never expose Entity beans directly to any client type. Only use Local EJB interfaces for Entity types.

Using a session facade is one of the best-established best practices for the use of EJB components. In fact, the general practice is widely advocated for any

distributed technology, including CORBA, EJB, and DCOM. Basically, the lower the distribution "cross-section" of your application, the less time will be wasted in overhead caused by multiple, repeated network hops for small pieces of data. The way to accomplish this is to create very large-grained facade objects that wrap logical subsystems and that can accomplish useful business functions in a single method call. Not only will this reduce network overhead, but within EJBs, it also critically reduces the number of database calls by creating a single transaction context for the entire business function. (This is described in detail in [Brown].

[Alur] has the canonical representation of this pattern, but it is also described in

[Fowler] (which generalizes it beyond just EJBs) and in [Marinescu]. See Resources.)

EJB local interfaces, introduced as part of the EJB 2.0 specification, provide performance optimization for co-located EJBs. Local interfaces must be explicitly called by your application, requiring code changes and preventing the ability to later distribute the EJB without application changes. Because the Session Facade and the entity EJBs it wraps should be local to each other, we recommend using local interfaces for the entity beans behind the Session Facade. However, the implementation of the Session Facade itself, typically a stateless session bean, should be designed for remote interfaces.

For performance optimization, a local interface can be added to the Session Facade. This takes advantage of the fact that most of the time, in Web applications at least, your EJB client and the EJB will be co-located within the same JVM. Alternatively, J2EE application server configuration optimizations, such as WebSphere "No Local Copies," can be used if the Session Facade is invoked locally. However, you must be aware these alternatives change the semantics of the interaction from pass-by-value to pass-by-reference. This can lead to subtle errors in your code. To take advantage of these options, you should plan for this possibility from the start.

If you use a remote interface (as opposed to a local interface) for your Session Facade, then you may also be able to expose that same Session Facade as a Web service in a J2EE 1.4 compliant way. (This is because JSR 109, the Web services deployment section of J2EE 1.4, requires you to use the remote interface of a stateless session bean as the interface between an EJB Web service and the

EJB implementation.) Doing so is often desirable, since it can increase the number of client types for your business logic.

中文翻译稿

翻译： 应用技术学院 06计算机1班（0616403082）高阳

20xx年2月

（中文名：Java EE最佳实践）

引言

在过去的五年，已经写了很多关于J2EE的最佳实践。现在大概有10本或者更多的书。除了几十篇对于应当怎样写J2EE应用提供了洞察力的文章。事实上，有如此多的资源，经常有矛盾的建议，导航迷宫已经成为一个障碍来采用J2EE本身。为了对客户进入这个迷宫提供一些简单的指导，我们着手编写了“十大”我们感觉是最重要的J2EE的最佳实践的清单。可惜的是，10并不足以获得需要说明的一切。尤其是当你把WEB服务开发作为J2EE的一部分。因此，为了纪念J2EE的发展，我们已经决定把我们的“十大”名单改为“十二大”名单。

最佳做法

1.始终使用MVC模式。

2.在每一层应用于自动化单元测试并保留测试结果。

3.制定计划书，而不是直接使用程序服务器。

4.从第一天开始就计划使用J2EE的安全模式。

5.建立你所知道的。

6.无论何时使用EJB组件始终使用Session Facades。

7.使用无状态会话beans而不是有状态会话beans 。

8.坚持使用容器管理器。

9.优先使用JSP作为您的第一代表技术。

10.当使用Http会话时，仅存储业主目前所需要的商业交易或类似的信息。

11.在Web领域 ，打开动态缓存和使用Web领域的servlet缓存机制。

12.基于程序员的开发效率优先选择CMP实体组件作为O/R图的第一通过的解答。

1.始终使用MVC模式

清晰的从控制器逻辑（Servlets Struts插件）和介绍（JSP技术和XML/XSL样式）中

区分业务逻辑（Java集合和EJB组件）。良好的分层可以涵盖许多的过错。

为了J2EE顺利的采用这种做法是如此的重要，以至于放在第一条是没有丝毫争议的。对于好的J2EE应用的设计，模型视图控制器（MVC）是基本的。以下部分是你的程序简单的分工：

a.那些负责业务逻辑（模型-通常实施采用的Enterprise Java ?集合或清晰的已有的Java对象）。

b.那些负责用户界面的显示（视图-通常执行JSP和标记库，但有时是XML和XSLT）。 c.这些是负责应用导航（控制器-通常执行Java Servlets或相关课程比如Struts的控制器）。

有许多出色的关于J2EE话题的评论，特别是我们有兴趣的读者从我们大量的资源中直接选取，以更好地理解J2EE。

有一些问题，可以从不服从下列基本的MVC架构。最严重的问题发生在太多的浏览部分的架构。做法是一样用JSP标记库来执行数据库访问，或在一个JSP中比较常见的小规模应用执行应用流量控制，但这些可能会导致JSPS在应用中更加难以维持和调试。

同样，我们常常看到视图层结构的迁移到业务逻辑。例如，一个共同的问题是推动在视图的结构中使用的XML解析技术到业务层。业务层应当在业务对象中操作-而不是帮到视图的一个特定数据的表示。

然而，仅仅有正确的成分不能使您的应用正确地分层。找到有servlets，JSPs和JSP这三个的应用是相当正常的，因为那里大多数的业务逻辑是在servlet层完成的，或者是应用程序导航是在JSP中处理的。您必须严格的对代码审查和重构，以确保业务逻辑只在模型层处理，应用导航仅仅是控制层的领域，而且你的意见只是涉及翻译的模型对象到适当的HTML和Javascript。

2.在每一层应用于自动化单元测试并保留测试结果

不要只是测试您的图形用户界面。分层测试可以使调试和维护大大简化。

在过去的几年中，已出现不少的改进后的方法，他们都自称很便捷，这已是很常见的了。几乎所有的这些方法都有一个共同的特征，就是他们鼓吹使用自动化测试工具，可以提高程序员的生产力，帮助开发人员花费更少的时间回归测试，并帮助他们避免在不足的回归测试中造成的错误。事实上，有一种做称为优先测试开发的做法通过采用优先写入实际代码本身的单元测试进一步采取了这种做法。然而，在您测试您的代码之前，您需要隔离到测试片段。一个“大泥球”是很难测试，因为它没有一个单一的，易于识别的功能。如果你的每个代码段做几件事情，就很难测试每行代码正确性。

MVC架构的好处之一就（MVC的J2EE的实施）是，元素的组件使测试你的片中的与应用程序变得可能（事实上，相对容易）。因此，您可以很容易的地编写测试来分别测试实体bean，会话bean，和JSP之外的代码库的其余部分。由许多用于J2EE测试的框架和工具，使得这个过程变得更容易。例如， JUnit ，它是用一种由junit.org ，和Cactus开发的一种开源工具，它是Apache财团的一个开源项目，对于测试J2EE组件都非常有用。Hightower详细的讨论J2EE这些工具的使用。

尽管在深入的测试应用程序时会产生大量的信息，我们仍然看到许多项目如果测试GUI （可能是一个基于Web的图形用户界面或一个独立的Java应用程序），他们都会全面测试整个应用程序。图形用户界面测试相当不够。有几个原因。第一，图形用户界面的测试，很难测试通过该系统每个路径。在GUI是影响系统的唯一方式。可能有背景工作，脚本和其他每个接入点都需要进行测试。然而在通常情况下他们是没有使用GUIS的。其次，在GUI层次上测试是非常粗糙的。该试验在宏观层面上测试系统该如何表现。这意味着，如果发现问题，整个子系统都必须加以考虑，使寻找漏洞更加困难。第三，图形用户界面测试通常不能做得很好，直到在开发周期后期的GUI才能充分确定。这意味着，潜在的错误将在很晚才会被发现。第四，并不是每个开发商都有权使用GUI自动测试工具。因此，一个开发人员对系统进行更改，没有简单的方法对子系统进行更改。这实际上阻碍了测试。如果开发商已经进入自动代码级单元测试，开发人员可以很容易地运行，以确保他们的变化不会打破现有的职能。最后，如果框架自动建立完成，这是很容易添加一个自动化单元测试套件来自动的创建进程。这样，该系统能被定期重建（通常很晚）和回归测试几乎没有人为的干预。

此外，我们必须强调指出，基于EJBs和Web服务的开发的分布式组件使得测试你自己的组件相当重要。如果不用“GUI”来测试，您必然会用比较落后的测试方法。最好是开始就这样做，这样就省下了你自己不得不改造你的进程头痛的部分，包括这些暴露了作为分布式组件或Web服务器的你的应用程序的一部分的时候的测试。

总之，通过使用自动单元测试，缺陷更容易被找到。缺陷越早找到，系统越容易修改。因此，整体素质得到提高。

3.制定规格，而不是应用程序服务器

记住说明和不同于只关心他们。因为有些事情你可以做并不意味着你应该这么做。 在J2EE允许的边缘，通过试着在周围找，这是很容易造成自己的错误。我们发现开发商为自己挖了一个洞，通过用他们认为J2EE允许的“好一点”的方法进行尝试，在执行中或迁移（从供应商到供应商，或更常见的从版本到版本）后才发现，它造成了严重的问

题。事实上，这样一个迁移的问题，Beaton呼吁将这一原则作为迁移工作的首要的做法。

在没有采取最直接的方法的几个地方，可以肯定将会造成很多问题。现在常见的就是开发商的J2EE安全通过使用JAAS的模块，而不是依赖于内置的规格兼容的应用服务器的机制，进行验证和授权。信赖J2EE规范所提供的验证机制的，这可能是发现安全漏洞和厂商的兼容性问题一个主要来源。同样，基于由 Servlet和EJB的规格提供的授权机制，而你必须超越他们，确保你使用了规范的API（如getCallerPrincipal（））为你实现的基础。这样，您将能够利用厂商提供了有力的安全基础设施，并在业务需求的情况下，支持更复杂的授权规则。

其他常见的问题包括：使用无关的基于J2EE规范（使事务管理困难）持续机制 ，依赖不适当的J2SE性能像J2EE程序里的线程或J2EE单程序， 和程序之间交互的“自己推动”的解决方案取代了停留在像JCA， JMS或Web服务的支持机制。当移动一个J2EE平台兼容的服务器到另一个，或当移动到新版本的同一台服务器上，这种设计的选择造成无止尽的困难。使用J2EE以外的内容往往导致微妙的可移植性问题。你应该永远偏离规范的唯一时候是当存在着明显的问题，它不能在规范中标记。例如，调度定时业务逻辑的执行是一个EJB 2.1介绍之前的问题。像这样的情况下，我们可能会建议使用提供商提供的解决方案，这个方案是可用的（如调度WebSphere的设施?企业服务器应用） ，或使用第三方工具，在这些都无法使用的地方。通过这种方式，维护和迁移到后期的规范版本的问题变成了供应商的问题，而不是你自己的问题。

最后，应注意采用新技术还为时过早。 Overzealously前通过了一项技术，在它已经被集成到其他的J2EE规范，或为一个厂商的产品前，虚假的采用一个技术往往会导致灾难。支持是相当重要的-如果您的厂商没有直接的支持在JSR中提出的某一特定技术但是也没有接受J2EE的规范，你或许不应去当追求它。毕竟，除了极少数的例外，我们大多数人是解决业务问题，而不是为了技术的纯粹取乐推进技术。

4.从第一天开始就计划使用J2EE的安全

打开Web领域的安全模式。对于至少所有的验证用户锁定所有你的EJB和URL。甚至不问—只要做。

对于我们来说与我们合作的一些客户原先是如何计划打开Web领域的J2EE安全是一个持续惊讶的来源。我们估计大约50%的顾客，我们最初看到计划使用此功能。例如，我们已经工作的一些主要的金融机构（银行，证券公司等等）并没有计划打开安全工作；幸运的是这个问题被放置在审查阶段来部署。

不利用J2EE安全性是一个危险的游戏。假设你的应用需要安全性（几乎所有都需要），

你正在打赌你的开发者能建立一个比在J2EE供应商买到的更安全的设备。那不是一个好的赌注。保证一个分布式应用是异常困难的。例如，你需要使用网络安全加密令牌来对EJB进行控制访问。根据我们的经验，大多数本土安全基础设施不可靠；离开生产系统的重要弱点极其地脆弱。（更多的参照Barcia的18章）

列举出的不使用J2EE安全性的理由包括：害怕性能恶化，认为其他的像Netegrity SiteMinder这样的产品处理这个，或者忽略Web领域应用服务安全的特性和功能。不要陷入这些陷阱。尤其，当如SiteMinder这样的产品提供优越的安全特性，他们本身并不能保证一个完整的J2EE应用。他们必须与J2EE应用服务携手合作来确保系统的所有方面。

另一个给出的不适用J2EE安全性的基本的原因是基于角色的模型没有提供足够地粒状访问控制来满足复杂的商业规则。尽管这是经常正确的，这不是一个避免J2EE安全性的原因。相反，利用J2EE的认证模式和结合你特定扩展规则的J2EE角色。如果在一个复杂的业务规则下需要用来做出一个安全决定，基于在容易的，可用的和值得信赖的J2EE验证信息上的决定（用户的ID和角色），编写代码来做到这一点。

5.建立你所知道的

迭代式开发，您可以逐渐掌握所有的J2EE集合。通过你的应用建立小的，垂直的片段而不是立刻做事。

让我们面对现实吧，J2EE是强大。如果开发团队刚刚开始接触J2EE，尝试着立刻了解它的所有是困难的。有太多的简单概念和API以至于很难学会。在这种环境中成功的关键是在小和控制措施上运用J2EE。

从你的应用中通过建立小，垂直片段是最好的实施的方法。一旦建立了一个团队的信任，通过建立一个简单的域模型和后端持续机制（或许可以使用JDBC），并经过全面测试的模型，就可以进入掌握前端开发与Servlets和JSPs使用该域模型。如果一个开发小组找到了EJB的需求 ，他们可以同样从移动到更复杂的构造类似消息驱动集和JMS之前的简单会话立面之上容器管理的持久性的EJB组件或基于JDBC的数据访问对象（DAOS）开始。

这种做法并不是什么新东西，但相对较少的团队实际上以这种方式建立自己的技能。相反，大多数的团队在一起通过试着马上建立一切来安排压力--他们同时攻击MVC中的视图层，模型层和控制器层。相反，考虑到一些新的敏捷开发方法，如极限编程（XP）中，以促进这种渐进的学习和发展。有一个程序经常被用来在XP中使用称为ModelFirst，组织和执行您的用户故事，[新闻]涉及建设领域模型首次作为一种机制。基本上，你建立的域模型作为你开发的第一套用户故事的一部分，然后在它的顶端建立一个UI作为实施

后来用户故事的结果。让一个团队一次学习一个技术，这非常的好，而不是将它们发送给12个同步班（或让他们读十几本书），这样会被压倒。

此外，每一个应用层的迭代式开发促进适当的模式的应用和最佳做法。如果你以你的应用的下层开始，并应用像数据访问对象和Session Facades那样的模型，你不应该在您的JSPs和其他视图对象结束域逻辑。

最后，当你在小的，垂直切片中作开发，它使得在测试你的应用程序的性能过早的开始变得更容易。延迟性能测试直到应用程序周期结束肯定是一个灾难，作为与 [Joines]有关。

6．无论何时创建对话框始终使用EJB组件

不要向任何客户类型直接暴露实体组件。对实体类型只使用本地EJB的接口。

使用的EJB组件时利用会议门面是最好的一个既定的最佳做法。事实上，一般的做法是广泛提倡任何分布式技术，包括CORBA ， EJB组件，和DCOM 。基本上，你的应用的"cross-section"的分配越低，那么由多种原因引起的开销就会被浪费的越少。重复数据小片的网络跳线。要做到这一点的方式是创造非常大的包装的逻辑子系统的正面对象，并且能够在一个单一的方法中完成有益的商务功能。这不仅会减少网络开销，但在EJBS ，也严重降低了通过为整个商业功能创造的一个单一的交易功能的数据库响应的数量。（这是在 [Brown] 中详细说明的。 [Alur]在这种模式中具有典型代表性，但它也在

[Fowler]（从而推广它不仅仅是EJBS）和[Marinescu]中说明。查看资源。 ）

EJB本地接口，正如EJB2.0规格部分中介绍的，为同一地点的EJB提供性能优化。本地接口通过你的应用必须被明确的支指出，需要代码改变以及为了后来的没有应用变更的发布EJB防止能力。因为Session Fa?ade和实体EJB的外包装应该相互布局，我们推荐为Session Fa?ade后的实体bean使用本地接口。然而，Session Fa?ade本身的实现，通常是一个无状态的session bean，应当被设计为远程接口。

对于性能优化，一个本地接口能被添加到Session Fa?ade。它利用了大部分时间这个事实。至少在Web应用程序，你的EJB客户端和EJB会一起位于同一JVM。另外，J2EE应用服务器配置优化，如果Session Fa?ade被本地调用，那么如Web领域“没有本地副本，”能够被使用。然而，你必须知道这些替代品改变了从价值传递到参考传递的相互作用的语义。这能导致你代码里细微的错误。利用这些选项，你应该一开始就计划它的可能性。

如果您使用远程接口（而不是本地接口）启动Session Facade，那么你也可以揭露Session Facade作为一个J2EE 1.4的Web服务中的兼容方式。 （这是JSR 109，J2EE 1.4的 Web服务部署部分，需要你使用远程端口作为EJB Web服务的EJB组件之间的接口。 ）

这样做，通常是可取的，因为它可以为您的业务逻辑增加一些客户类型。