相关图书推荐
同类热销商品
您的浏览历史
Expert One-on-One J2EE Development without EJB中文版
|
促销活动
|
点击看大图基本信息
- 作者： （美）Rod Johnson,Juergen Hoeller [作译者介绍]
- 译者： JavaEye[同译者作品]
- 出版社：电子工业出版社
- ISBN：7121016842
- 上架时间：2005-9-21
- 出版日期：2005 年8月
- 开本：16开
- 页码：552
- 版次：1-1
- 所属分类：
计算机 > 软件与程序设计 > JAVA >
J2EE
编辑推荐
J2EE领域/Web开发中的里程碑之作!
2005年十大电脑好书之一!
2005年连续三个月荣登互动网销售第一名!
内容简介回到顶部↑
这本书拥有一大堆“看点”。譬如说，它的作者Rod Johnson拥有10年编写Java程序的经验，目前是Servlet和JDO 2.0两个JSR专家组的成员；再譬如说，书中着力介绍的Spring、Hibernate、WebWork等都是时下流行的开源框架，IoC、AOP之类都是时下流行的概念词汇。而最大的看点就赫然摆在这本书的封面上：“without EJB”。我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson的这本书竟然宣称，绝大多数的J2EE应用根本不需要EJB。这种近乎挑衅的姿态令任何一个负责的J2EE架构师很难不萌生一探究竟的念头--不论你是打算赞同他还是打算驳斥他。
但所有这些尽皆不是本书最大的价值所在。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这种“循证方法”的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原本就应该是程序员的工作方式。
但所有这些尽皆不是本书最大的价值所在。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这种“循证方法”的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原本就应该是程序员的工作方式。
作译者回到顶部↑
本书提供作译者介绍
Rod Johnson是一名企业Java架构师，在保险、电子商务和金融行业的信息化领域有丰富的经验。他是欧洲最大的门户网站之一的J2EE架构师，并且以顾问的身份参与了大量的项目。
Rod在悉尼大学(University of Sydney)获得了音乐和计算机科学的学位。在回到软件开发领域之前，他还获得了音乐学的博士学位。他有相当深厚的C／C++技术背景，并且从Java和J2EE发布之初就已经开始使用它们。他积极地参与到Java社群过程(JCP)之中，是JSR-154(Servlet 2．4)和JDO 2．0规范专家组的成员。自2000年以来，他参与写.. << 查看详细
Rod在悉尼大学(University of Sydney)获得了音乐和计算机科学的学位。在回到软件开发领域之前，他还获得了音乐学的博士学位。他有相当深厚的C／C++技术背景，并且从Java和J2EE发布之初就已经开始使用它们。他积极地参与到Java社群过程(JCP)之中，是JSR-154(Servlet 2．4)和JDO 2．0规范专家组的成员。自2000年以来，他参与写.. << 查看详细
目录回到顶部↑
第1章 为什么要“J2EE Without EJB”
聚光灯下的EJB
J2EE还剩什么？
站在十字路口的J2EE
前行的路
主旋律
轻量级框架和容器
我们还应该使用EJB吗？
小结
第2章 目标
生产率
问题
传统J2EE方案解决生产率问题的办法
提升生产率更好的办法
OO
业务需求的重要性
经验过程的重要性
小结
第3章 各种架构
架构性构件
聚光灯下的EJB
J2EE还剩什么？
站在十字路口的J2EE
前行的路
主旋律
轻量级框架和容器
我们还应该使用EJB吗？
小结
第2章 目标
生产率
问题
传统J2EE方案解决生产率问题的办法
提升生产率更好的办法
OO
业务需求的重要性
经验过程的重要性
小结
第3章 各种架构
架构性构件
译者序回到顶部↑
几年以后，当人们重新审视这本《Expert One-on-One J2EE Development without EJB》时，他们会记起这本书曾经如何引领J2EE架构与开发的潮流。
作为译者，我可不毫不费力地帮这本书找出一大堆“看点”。譬如说，它的作者Rod Johnson 拥有10编写Java程序的经验——那正是JAVA诞生至今的时间，他目前是Servlet 和JDO2.0两个JSR专家组的成员，他的前一本书《Expert One-on-One J2EE Design and Development (Programmer to Programmer)》曾经风靡一时；再譬如说，书中着力介绍的Spring、Hibernate、WebWork 等都是时下流行的概念词汇。而最大的看点就赫然摆在这本书的封面上：”without EJB”。我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson 的这本书竟然宣称，绝大多数的J2EE应用根本不需要EJB。这种近乎挑衅的姿态令任何一个负责的J2EE架构师很难不萌生一探窨的念头——无论你是打赞同他还是打算驳斥他。
然而在我看来，所有这些都有其价值，但皆不是本书最大的价值所在。任何一个从事J2EE应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和“大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道追随这位导师还是信奉那个门派。这时Rod Johnson发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身——这就是他在书中一直倡导的“循证架构”（evidence-base architecture）。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这是种：循证方法的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原来就应该是程序的工作方式。
所以，在这篇译序里，我可以负责任地告诉你：那看上去有些骇人听闻的without EJB字样仅仅是Rod Johnson用来吸引你的一个噱头而已——EJB诞生至今已经有7年之久，如果今天的J2EE应用仍旧不能摆脱这样一种“古老”的技术。岂不为天下笑？这里的关键是：EJB正是Java世界里最大的“泥胎偶像”，围绕着它的门派之争历来激烈无比。透过“without EJB”这个标题，Rod Johnson真正想说的是“without buzzword”——扔掉一切可笑的门户偏见，不再仅仅因为看到“EJB”这么一个貌似神秘的缩写词而奉若圭臬或是弃若敝屣，完全根据技术本身和实打实的经验来判断是否使用、如何使用一种技术，这才是Rod Johnson希望传递给读者的态度。
于是你可以想念我在开头处说的那句话并非夸大其词：你手上的这本《Expert One-on-One J2EE Development without EJB》将会引领一种影响深远的潮流。但这潮流不是Spring和Hibernate,也不是IoC和AOP,甚至不是“轻量级架构”，而是一切实事求是的“循证架构”的工作方式。惟有掌握这种工作方式，你才能够真正自信满满地挺起胸膛说：“我选择的架构是适合应用需求的架构。”毕竟，衡量架构师价值的标准不应该是他知道多少概念，而是他能否做出合乎需求的架构。
“可是，”有人说“我一直都是按照别人/网上/书上的建议来做架构的。要亲自考察各种各样的技术，还要根据项目情况比较它们的优劣，我可没这份时间。”
那么，他也应该没有时间去做架构。
这本《Expert One-on-One J2EE Development without EJB》涵盖了J2EE应用架构的方方面面，以其内容之丰、跨度之大，要翻译它已经超出了笔者的能力范畴。幸而得到其他7位专家鼎力相助，方能顺利完成翻译工作。读者若是能从书中有所收获，全赖7位专家对技术准确到位的理解和阐述。除翻译之处，笔者还负责全书的文字修润，如果读者感觉本书读来诘屈聱牙，责任全在我一人身上。
由于本书是众人集体劳动的结晶，参与翻译工作的诸人又都是通过网络彼此结识，是以深感网上技术社群的重要性。本书给译者带来的所有收将全部捐献给身患生病的程序员王俊，希望他能够早日康复。
最后，祝您阅读愉快。
作为译者，我可不毫不费力地帮这本书找出一大堆“看点”。譬如说，它的作者Rod Johnson 拥有10编写Java程序的经验——那正是JAVA诞生至今的时间，他目前是Servlet 和JDO2.0两个JSR专家组的成员，他的前一本书《Expert One-on-One J2EE Design and Development (Programmer to Programmer)》曾经风靡一时；再譬如说，书中着力介绍的Spring、Hibernate、WebWork 等都是时下流行的概念词汇。而最大的看点就赫然摆在这本书的封面上：”without EJB”。我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson 的这本书竟然宣称，绝大多数的J2EE应用根本不需要EJB。这种近乎挑衅的姿态令任何一个负责的J2EE架构师很难不萌生一探窨的念头——无论你是打赞同他还是打算驳斥他。
然而在我看来，所有这些都有其价值，但皆不是本书最大的价值所在。任何一个从事J2EE应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和“大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道追随这位导师还是信奉那个门派。这时Rod Johnson发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身——这就是他在书中一直倡导的“循证架构”（evidence-base architecture）。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这是种：循证方法的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原来就应该是程序的工作方式。
所以，在这篇译序里，我可以负责任地告诉你：那看上去有些骇人听闻的without EJB字样仅仅是Rod Johnson用来吸引你的一个噱头而已——EJB诞生至今已经有7年之久，如果今天的J2EE应用仍旧不能摆脱这样一种“古老”的技术。岂不为天下笑？这里的关键是：EJB正是Java世界里最大的“泥胎偶像”，围绕着它的门派之争历来激烈无比。透过“without EJB”这个标题，Rod Johnson真正想说的是“without buzzword”——扔掉一切可笑的门户偏见，不再仅仅因为看到“EJB”这么一个貌似神秘的缩写词而奉若圭臬或是弃若敝屣，完全根据技术本身和实打实的经验来判断是否使用、如何使用一种技术，这才是Rod Johnson希望传递给读者的态度。
于是你可以想念我在开头处说的那句话并非夸大其词：你手上的这本《Expert One-on-One J2EE Development without EJB》将会引领一种影响深远的潮流。但这潮流不是Spring和Hibernate,也不是IoC和AOP,甚至不是“轻量级架构”，而是一切实事求是的“循证架构”的工作方式。惟有掌握这种工作方式，你才能够真正自信满满地挺起胸膛说：“我选择的架构是适合应用需求的架构。”毕竟，衡量架构师价值的标准不应该是他知道多少概念，而是他能否做出合乎需求的架构。
“可是，”有人说“我一直都是按照别人/网上/书上的建议来做架构的。要亲自考察各种各样的技术，还要根据项目情况比较它们的优劣，我可没这份时间。”
那么，他也应该没有时间去做架构。
这本《Expert One-on-One J2EE Development without EJB》涵盖了J2EE应用架构的方方面面，以其内容之丰、跨度之大，要翻译它已经超出了笔者的能力范畴。幸而得到其他7位专家鼎力相助，方能顺利完成翻译工作。读者若是能从书中有所收获，全赖7位专家对技术准确到位的理解和阐述。除翻译之处，笔者还负责全书的文字修润，如果读者感觉本书读来诘屈聱牙，责任全在我一人身上。
由于本书是众人集体劳动的结晶，参与翻译工作的诸人又都是通过网络彼此结识，是以深感网上技术社群的重要性。本书给译者带来的所有收将全部捐献给身患生病的程序员王俊，希望他能够早日康复。
最后，祝您阅读愉快。
前言回到顶部↑
就其涵盖的范围而言，读者捧在手中的这本书已经算得上短小轻薄了，这是因为本书所讲述的主题并不像你所想象的那么复杂。
J2EE的“正统”使得人们在很多简单的问题上投入了大量的精力。说实话，J2EE行业的情况常常会让人感到：这些人坚信世界上根本就没有简单的问题。
很多——也许是绝大多数——J2EE应用程序都遭遇了过度工程，并因此拥有一个毫无必要的、复杂的体系结构。过度工程会带来巨大的开销，而J2EE开发者们往往一厢情愿地认为：复杂的体系结构能够极大地降低未来的成本，足以抵消前期增加的成本。可惜，这样的因果关系在软件工程领域通常是痴人说梦。预先设计的复杂度越高，就意味着有越多的代码需要编写和维护，意味着系统中潜伏着越多的bug，意味着需要越多的时间才能向用户展示系统的功能。说到底，预先设计的复杂度越高，失败的机会就越大，成本开销也越高。
J2EE的过度工程多半与EJB有关。正如我在Expert One-on-One J2EE Design and Development中曾经说过的，EJB常常被误用。这是一个严重的问题，因为EJB有可能带来巨大的复杂度——甚至比它所掩盖起来的复杂度还要大。而且，EJB提供的一些服务也被过高地估计了。譬如说，大凡有经验的开发者和架构师，只要用实体EJB访问过关系型数据，几乎没有谁愿意重复这个痛苦的经历——至少，如果有JDO、Hibernate和其他的透明持久化技术可供选择的话。
从2002年末开始，对EJB的批评逐渐成了家常便饭。对于一种并不完美的技术，挑毛病总是很容易的，而找出合适的替代品就不那么容易了。大多数J2EE应用程序并不能从EJB那里得到更多的利益，本书便为这些项目的开发者指出了一条更好的新路。本书并不是纯粹的理论探讨，而是对于“如何在有限的时间和预算范围内设计、实现高性能J2EE应用程序”的实践指南。我们推荐的体系结构来自大量的经验，而且有众多开源解决方案能够满足其中常见的基础设施需求，我们还根据这个体系结构创建了一个极具现实意义的示例应用，这些都足以证明它的价值。
尽管EJB已经暴露出很多问题，但它仍然被大量采用，原因无外两种：“流行”和“恐惧”。EJB一度非常流行，就连不懂技术的管理者们也多少听说过它的大名，关于J2EE体系结构的书籍也很少提到EJB的替代品——尽管确实有一些出类拔萃的替代品存在。而且，人们还害怕这些替代品会使情况变得更糟。譬如一种常见的论调说：如果没有EJB容器的帮助，开发者们就得亲手解决诸如事务管理之类复杂的问题。本书将让读者看到：这些恐惧大多是毫无根据的。在每一处潜藏着复杂问题的地方，读者都将看到：EJB的替代品们以更为精彩的方式解决了这些问题。
本书所介绍的架构方案是J2EE体系结构朝着更简单、更理性的方向迈出的第一步，它适于与敏捷方法结合使用。我们的方案采用了面向方面的程序设计(Aspect Oriented Programming，AOP)等新近发展的技术，并且从．NET等与J2EE竞争的平台借鉴了很多有益的思想。
作为本书的作者，我希望能够帮助读者搭建能够满足需求的、尽可能简单的应用程序——自然，也应该是最便宜、最具可维护性和可测试性的应用程序。
令人惊讶地，“EJB之优劣”在J2EE社群中已经成了一个感情问题。在这个问题上，J2EE社群呈现出一种彻底的两极分化：要么是除非被逼无奈、否则决不使用EJB；要么是认为大凡怀疑EJB的人都是懒惰无知的异教徒，几乎没有任何中间派。
读者大概都知道，我不是EJB的支持者，但我也曾经用EJB开发过很多应用程序。我对于EJB的任何观点，都源于丰富的个人经验和对EJB规范的深入了解。在本书中，我也努力澄清自己在这个问题上的立场：我的目标是帮助读者开发出色的应用程序，而不是对抗EJB。读完本书之后，你应该有能力评估EJB在每个应用程序中的价值。如果在充分了解EJB及其替代品之后，你仍然坚信EJB能够最好地满足你的需求，就使用EJB吧。本书不会黑白分明地对读者说“不要使用EJB”，但你必须清楚了解自己的选择。
本书为谁而作
本书的目标读者是对技术有充分把握、希望更加有效地使用技术的J2EE架构师和开发者。本书的内容是企业应用开发中的“why”和“how”，而不仅仅是“what”。所以，在这里你看不到API的列举，也看不到对J2EE基础服务(例如JNDI和JTA)的介绍——有很多书和文章已经介绍了这些主题。
对于web应用的开发者来说，本书中的内容尤其有用。不过，即便不是开发web应用，绝大多数J2EE开发者仍然能够从中找到一些有价值的东西。也许读完本书以后，你会断定EJB正是适合你的选择，即便如此，按照本书所提出的标准，你也能够清楚地知道自己为
什么使用EJB、EJB究竟为你提供了哪些价值。
本书的目标
本书的目标是要帮助读者解决实际问题。我们希望借本书向读者展示一种——与Sun公司的蓝图应用所展示的、基于EJB来管理业务逻辑的传统J2EE方案相比——更为简单有效的J2EE开发之道。
当然，我们也希望能给读者带来更多的快乐。
本书有哪些内容
本书涵盖了下列内容：
□ EJB存在的问题和J2EE架构的常识；
J2EE的“正统”使得人们在很多简单的问题上投入了大量的精力。说实话，J2EE行业的情况常常会让人感到：这些人坚信世界上根本就没有简单的问题。
很多——也许是绝大多数——J2EE应用程序都遭遇了过度工程，并因此拥有一个毫无必要的、复杂的体系结构。过度工程会带来巨大的开销，而J2EE开发者们往往一厢情愿地认为：复杂的体系结构能够极大地降低未来的成本，足以抵消前期增加的成本。可惜，这样的因果关系在软件工程领域通常是痴人说梦。预先设计的复杂度越高，就意味着有越多的代码需要编写和维护，意味着系统中潜伏着越多的bug，意味着需要越多的时间才能向用户展示系统的功能。说到底，预先设计的复杂度越高，失败的机会就越大，成本开销也越高。
J2EE的过度工程多半与EJB有关。正如我在Expert One-on-One J2EE Design and Development中曾经说过的，EJB常常被误用。这是一个严重的问题，因为EJB有可能带来巨大的复杂度——甚至比它所掩盖起来的复杂度还要大。而且，EJB提供的一些服务也被过高地估计了。譬如说，大凡有经验的开发者和架构师，只要用实体EJB访问过关系型数据，几乎没有谁愿意重复这个痛苦的经历——至少，如果有JDO、Hibernate和其他的透明持久化技术可供选择的话。
从2002年末开始，对EJB的批评逐渐成了家常便饭。对于一种并不完美的技术，挑毛病总是很容易的，而找出合适的替代品就不那么容易了。大多数J2EE应用程序并不能从EJB那里得到更多的利益，本书便为这些项目的开发者指出了一条更好的新路。本书并不是纯粹的理论探讨，而是对于“如何在有限的时间和预算范围内设计、实现高性能J2EE应用程序”的实践指南。我们推荐的体系结构来自大量的经验，而且有众多开源解决方案能够满足其中常见的基础设施需求，我们还根据这个体系结构创建了一个极具现实意义的示例应用，这些都足以证明它的价值。
尽管EJB已经暴露出很多问题，但它仍然被大量采用，原因无外两种：“流行”和“恐惧”。EJB一度非常流行，就连不懂技术的管理者们也多少听说过它的大名，关于J2EE体系结构的书籍也很少提到EJB的替代品——尽管确实有一些出类拔萃的替代品存在。而且，人们还害怕这些替代品会使情况变得更糟。譬如一种常见的论调说：如果没有EJB容器的帮助，开发者们就得亲手解决诸如事务管理之类复杂的问题。本书将让读者看到：这些恐惧大多是毫无根据的。在每一处潜藏着复杂问题的地方，读者都将看到：EJB的替代品们以更为精彩的方式解决了这些问题。
本书所介绍的架构方案是J2EE体系结构朝着更简单、更理性的方向迈出的第一步，它适于与敏捷方法结合使用。我们的方案采用了面向方面的程序设计(Aspect Oriented Programming，AOP)等新近发展的技术，并且从．NET等与J2EE竞争的平台借鉴了很多有益的思想。
作为本书的作者，我希望能够帮助读者搭建能够满足需求的、尽可能简单的应用程序——自然，也应该是最便宜、最具可维护性和可测试性的应用程序。
令人惊讶地，“EJB之优劣”在J2EE社群中已经成了一个感情问题。在这个问题上，J2EE社群呈现出一种彻底的两极分化：要么是除非被逼无奈、否则决不使用EJB；要么是认为大凡怀疑EJB的人都是懒惰无知的异教徒，几乎没有任何中间派。
读者大概都知道，我不是EJB的支持者，但我也曾经用EJB开发过很多应用程序。我对于EJB的任何观点，都源于丰富的个人经验和对EJB规范的深入了解。在本书中，我也努力澄清自己在这个问题上的立场：我的目标是帮助读者开发出色的应用程序，而不是对抗EJB。读完本书之后，你应该有能力评估EJB在每个应用程序中的价值。如果在充分了解EJB及其替代品之后，你仍然坚信EJB能够最好地满足你的需求，就使用EJB吧。本书不会黑白分明地对读者说“不要使用EJB”，但你必须清楚了解自己的选择。
本书为谁而作
本书的目标读者是对技术有充分把握、希望更加有效地使用技术的J2EE架构师和开发者。本书的内容是企业应用开发中的“why”和“how”，而不仅仅是“what”。所以，在这里你看不到API的列举，也看不到对J2EE基础服务(例如JNDI和JTA)的介绍——有很多书和文章已经介绍了这些主题。
对于web应用的开发者来说，本书中的内容尤其有用。不过，即便不是开发web应用，绝大多数J2EE开发者仍然能够从中找到一些有价值的东西。也许读完本书以后，你会断定EJB正是适合你的选择，即便如此，按照本书所提出的标准，你也能够清楚地知道自己为
什么使用EJB、EJB究竟为你提供了哪些价值。
本书的目标
本书的目标是要帮助读者解决实际问题。我们希望借本书向读者展示一种——与Sun公司的蓝图应用所展示的、基于EJB来管理业务逻辑的传统J2EE方案相比——更为简单有效的J2EE开发之道。
当然，我们也希望能给读者带来更多的快乐。
本书有哪些内容
本书涵盖了下列内容：
□ EJB存在的问题和J2EE架构的常识；
序言回到顶部↑
循证潮流的引领者
熊节
几年以后，当人们重新审视这本《Expert One-on-One J2EE Development without EJB》时，他们会记起这本书曾经如何引领J2EE架构与开发的潮流。
作为译者，我可不毫不费力地帮这本书找出一大堆“看点”。譬如说，它的作者Rod Johnson 拥有10编写Java程序的经验——那正是JAVA诞生至今的时间，他目前是Servlet 和JDO2.0两个JSR专家组的成员，他的前一本书《Expert One-on-One J2EE Design and Development (Programmer to Programmer)》曾经风靡一时；再譬如说，书中着力介绍的Spring、Hibernate、WebWork 等都是时下流行的概念词汇。而最大的看点就赫然摆在这本书的封面上：”without EJB”。我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson 的这本书竟然宣称，绝大多数的J2EE应用根本不需要EJB。这种近乎挑衅的姿态令任何一个负责的J2EE架构师很难不萌生一探窨的念头——无论你是打赞同他还是打算驳斥他。
然而在我看来，所有这些都有其价值，但皆不是本书最大的价值所在。任何一个从事J2EE应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和“大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道追随这位导师还是信奉那个门派。这时Rod Johnson发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身——这就是他在书中一直倡导的“循证架构”（evidence-base architecture）。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这是种：循证方法的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原来就应该是程序的工作方式。
所以，在这篇译序里，我可以负责任地告诉你：那看上去有些骇人听闻的without EJB 字样仅仅是Rod Johnson用来吸引你的一个噱头而已——EJB诞生至今已经有7年之久，如果今天的J2EE应用仍旧不能摆脱这样一种“古老”的技术。岂不为天下笑？这里的关键是：EJB正是Java世界里最大的“泥胎偶像”，围绕着它的门派之争历来激烈无比。透过“without EJB”这个标题，Rod Johnson真正想说的是“without buzzword”——扔掉一切可笑的门户偏见，不再仅仅因为看到“EJB”这么一个貌似神秘的缩写词而奉若圭臬或是弃若敝屣，完全根据技术本身和实打实的经验来判断是否使用、如何使用一种技术，这才是Rod Johnson希望传递给读者的态度。
于是你可以想念我在开头处说的那句话并非夸大其词：你手上的这本《Expert One-on-One J2EE Development without EJB》将会引领一种影响深远的潮流。但这潮流不是Spring和Hibernate,也不是IoC和AOP,甚至不是“轻量级架构”，而是一切实事求是的“循证架构”的工作方式。惟有掌握这种工作方式，你才能够真正自信满满地挺起胸膛说：“我选择的架构是适合应用需求的架构。”毕竟，衡量架构师价值的标准不应该是他知道多少概念，而是他能否做出合乎需求的架构。
“可是，”有人说“我一直都是按照别人/网上/书上的建议来做架构的。要亲自考察各种各样的技术，还要根据项目情况比较它们的优劣，我可没这份时间。”
那么，他也应该没有时间去做架构。（本文选自即将出版的《Expert One-on-One J2EE Development without EJB中文版》一书译者序，并有所删改。）——摘自中华读书报
熊节
几年以后，当人们重新审视这本《Expert One-on-One J2EE Development without EJB》时，他们会记起这本书曾经如何引领J2EE架构与开发的潮流。
作为译者，我可不毫不费力地帮这本书找出一大堆“看点”。譬如说，它的作者Rod Johnson 拥有10编写Java程序的经验——那正是JAVA诞生至今的时间，他目前是Servlet 和JDO2.0两个JSR专家组的成员，他的前一本书《Expert One-on-One J2EE Design and Development (Programmer to Programmer)》曾经风靡一时；再譬如说，书中着力介绍的Spring、Hibernate、WebWork 等都是时下流行的概念词汇。而最大的看点就赫然摆在这本书的封面上：”without EJB”。我们曾经在无数的书籍和文章中看到，EJB是J2EE的核心技术之一；而Rod Johnson 的这本书竟然宣称，绝大多数的J2EE应用根本不需要EJB。这种近乎挑衅的姿态令任何一个负责的J2EE架构师很难不萌生一探窨的念头——无论你是打赞同他还是打算驳斥他。
然而在我看来，所有这些都有其价值，但皆不是本书最大的价值所在。任何一个从事J2EE应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和“大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道追随这位导师还是信奉那个门派。这时Rod Johnson发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身——这就是他在书中一直倡导的“循证架构”（evidence-base architecture）。选择一种架构、一种技术的依据是什么？Rod Johnson认为，应该是基于实践的证据、来自历史项目或亲自试验的经验，而不是任何形式的偶像崇拜或者门户之见。书中谈到了企业应用方方面面的问题和解决办法，而这些方案无一不是这是种：循证方法的产物。除了把这些方案交给读者，Rod Johnson通过这本书希望传达的、更为重要的信息正是“循证”的工作方式——那原来就应该是程序的工作方式。
所以，在这篇译序里，我可以负责任地告诉你：那看上去有些骇人听闻的without EJB 字样仅仅是Rod Johnson用来吸引你的一个噱头而已——EJB诞生至今已经有7年之久，如果今天的J2EE应用仍旧不能摆脱这样一种“古老”的技术。岂不为天下笑？这里的关键是：EJB正是Java世界里最大的“泥胎偶像”，围绕着它的门派之争历来激烈无比。透过“without EJB”这个标题，Rod Johnson真正想说的是“without buzzword”——扔掉一切可笑的门户偏见，不再仅仅因为看到“EJB”这么一个貌似神秘的缩写词而奉若圭臬或是弃若敝屣，完全根据技术本身和实打实的经验来判断是否使用、如何使用一种技术，这才是Rod Johnson希望传递给读者的态度。
于是你可以想念我在开头处说的那句话并非夸大其词：你手上的这本《Expert One-on-One J2EE Development without EJB》将会引领一种影响深远的潮流。但这潮流不是Spring和Hibernate,也不是IoC和AOP,甚至不是“轻量级架构”，而是一切实事求是的“循证架构”的工作方式。惟有掌握这种工作方式，你才能够真正自信满满地挺起胸膛说：“我选择的架构是适合应用需求的架构。”毕竟，衡量架构师价值的标准不应该是他知道多少概念，而是他能否做出合乎需求的架构。
“可是，”有人说“我一直都是按照别人/网上/书上的建议来做架构的。要亲自考察各种各样的技术，还要根据项目情况比较它们的优劣，我可没这份时间。”
那么，他也应该没有时间去做架构。（本文选自即将出版的《Expert One-on-One J2EE Development without EJB中文版》一书译者序，并有所删改。）——摘自中华读书报
加载中...