J2EE Development without EJB序言的第一部分的翻译

This is a fairly short book, given its scope, because its subject is less complex than you’ve been led to
believe.
考虑到它讨论的领域，这确实是一本比较薄的书。因为这本书的主题比使你信任的东西更加简单。

J2EE orthodoxy makes heavy work of many simple problems. Indeed it sometimes seems that the J2EE
industry is committed to the belief that there are no simple problems.
正统的J2EE人员已经在许多简单的问题上做了大量的工作。以至于在J2EE社区经常认为根本没有简单的事情。

Many―probably most―J2EE applications are over-engineered, with unnecessarily complex architectures.
Over-engineering can be very costly. J2EE developers tend to assume that increased cost up front
will be more than balanced by reductions in future costs. Unfortunately, karma doesn’t apply to software
engineering, and this is often a fallacy. Greater complexity up front means more code to write and maintain,
more potential for bugs, more delay in demonstrating functionality to users: ultimately, greater
chance of failure, and at greater cost.
许多，可能是大多数J2EE应用程序都是过度工程：使用了不必要的复杂架构。而过度工程往往带来高成本。同时，J2EE的开发者往往假设在项目前期增加的开支将被后期节省的开支所抵消。不幸的是，因果报应并不适合软件工程，甚至在大多数情况下是一个错误的观点。项目前期大的复杂性带来的是：需要写更多和维护更多的代码，更多潜在的bug，向用户展示功能时更可能的延迟。最终导致更大可能性的失败和更大的开发和维护成本。

J2EE over-engineering usually involves EJB. As I pointed out in Expert One-on-One J2EE Design and
Development, EJB is often used inappropriately. This is a real problem, because EJB can introduce more
complexity than it conceals. Some services provided by EJB are also overrated. For example, few experienced
developers or architects who have worked with entity EJBs to access relational data want to repeat
the experience―at least, given the alternatives of JDO, Hibernate, and other transparent persistence
technologies.
J2EE的过度工程玩玩包括EJB的使用。象我在“Expert One-on-One J2EE Design and
Development”一书中指出的，EJB经常被不恰当的使用。这是一个现实的问题。因为EJB的引入可能导致带来超过它减少的复杂性的更大的复杂性。EJB提供的一些服务也被过度的加以赞扬。比如：和JDO，Hibernate和其他持久性技术相比，没有多少有经验，使用过实体EJB来访问关系数据库的开发者和架构师愿意再次使用它。

Critiques of EJB have become commonplace since late 2002. It’s easy enough to pick the flaws in an
imperfect existing technology, without suggesting alternatives. This book breaks new ground in describing
and illustrating better approaches for the majority of J2EE applications that derive no benefit from
EJB. This book is no mere theoretical discussion, but a practical guide to designing and implementing
high-performance J2EE applications on time and budget. Our suggested architectures are backed up by
extensive experience, a realistic sample application, and comprehensive open source solutions that meet
typical infrastructure needs.
在2002年以后，EJB受到批评已经是一件很平常的事情。对于已有的本身存在缺陷的技术支持它的缺点，而不提出相应的解决方案是一件非常容易的事情。这本书从另外的角度阐述对于主流的使用EJB带来不利影响的J2EE应用程序的更好的替代方案。这本书并不仅仅是理论上的争论，更是对按时、按预算设计和维护高效率的J2EE应用程序提出了实际的指南。我们建议的架构是基于长时间的开发经历，实际的简单应用程序和适合典型的架构基础需要的复杂开源解决方案。

Despite the significant problems that have emerged with EJB, it continues to be adopted too often largely
because of fashion and fear. Fashion because even nontechnical managers have heard of EJB and because
many books on J2EE architecture barely mention alternatives to EJB for delivering enterprise services,
even where excellent alternatives exist. Fear that the alternatives are worse: for example, that without
EJB developers will be left to handle complex issues such as transaction management without the training
wheels of the EJB container. This book aims to show that these fears are largely unfounded. Where
the potential complexity is real, it shows that there are alternatives that do a better job than EJB at
addressing the problems concerned.
尽管EJB带来了很多明显的问题，EJB技术还是因为流行和恐慌被大量的使用。流行是因为非技术的管理者都知道EJB技术；也因为大量的J2EE架构方面的书籍很少提到EJB提供的企业服务方面的替代技术，即使已经存在更好的解决方案。恐慌是因为害怕EJB技术的替代技术比EJB更差。比如，害怕没有EJB开发人员来处理复杂的问题，象事务管理。这本书的目的是说明恐慌是不必要的。当存在实际的复杂性的时候，我们揭示了解决相关问题的比EJB更好的解决方案。

This book demonstrates a much simpler approach to developing typical J2EE applications
than the “classic” J2EE blueprints approach exemplified by the original Java
Pet Store. Our approach leads to reduced cost, shorter time to market, greater maintainability,
and better performance.

The architectural approach described in this book is part of a growing movement towards simpler, more
rational J2EE architectures. It’s suitable for use with agile methodologies. It draws on recently developed
technologies such as Aspect Oriented Programming, and borrows where appropriate from alternative
platforms to J2EE such as .NET.
这本书描述的架构是向追求更简单，更理性的J2EE架构运动中的一部分。它适合敏捷方法论者。它吸收了最新的技术，包括：AOP，从J2EE技术的竞争者.NET平台上的合理借鉴。

I aim to help you build the simplest possible applications that meet your requirements―and hence, also
the cheapest, most maintainable and testable.

The merits of EJB have become a surprisingly emotive issue in the J2EE community. There seems to be a
stark polarization between those would never use EJB unless compelled and those who believe that the
EJB skeptics are lazy, ignorant heretics, with little middle ground.
EJB的价值已经令人惊奇的成为J2EE社区的感情相关的问题。似乎出现了两种极端的情况，一种是除非被迫否则决不使用EJB，一种是认为EJB的怀疑者都是懒惰的，无知的异教徒。而很少有位于这两者的中间情况。

As you may suspect, I’m not a fan of EJB. However, I have developed many applications with EJB and
speak from experience and intimate knowledge of the EJB specification. I’ll also strive to justify my position
throughout this book. My goal is to help you develop effective applications, not to combat the use of EJB.
After reading this book, you should be able to assess the value proposition of EJB for each application. If,
with a strong understanding of EJB and the alternatives, you believe that your requirements are best
addressed by EJB, use EJB. The message of this book is not a black-and-white “don’t use EJB.”
你可能怀疑，我并不是一个EJB的狂热支持者。但，我已经使用EJB技术开发了许多应用系统并且发表了实际的经历和EJB说明方面的意见和看法。我的目标是帮助你开发高效的应用程序而不是如何努力使用EJB。读完这本书，你应该能够判断EJB在每个应用中的价值。如果，在充分理解了EJB和替代技术的情况下，你相信EJB能够最好的解决你的需求，使用EJB。这本书并不是对于EJB的简单的非黑即白的“决不使用EJB”的建议。