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

huzhigang發表於2004-08-27
dev
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”的建議。

相關文章