expert one-on-one J2EE Development without EJB 中文版

出版时间：2005-9  出版社：电子工业  作者：詹森  页数：552  
Tag标签：无  

内容概要

　　你的J2EE项目是否耗费了你太多的时间？它们是否难以调试？它们是否效率不彰？也许你还在使用传统的J2EE方案，然而这种主案太过复杂，而且并非真正面向对象。这里的很多问题都与EJB有关：EJB是一种复杂的技术，但它没有兑现自己曾经的承诺。　　在这本实战手册中，你将看到另一种截然不同的方案：没有EJB，却可以创建质量更高的应用程序，所需的时间和成本则更低。你将学会如何充分利用各种实用的技巧和工具，包括时下流行的Spring框架和Hibernate两个开源工具。你将看到如何高效地解决企业级应用的核心问题，例如事务管理、持久化、远程调用和web设计。你将了解这种新的方案给可测试性、性能和可伸缩性带来怎样的影响，并亲身体验轻量级架构如何大幅降低项目开发所需的时间和工作量。　　自从servlet、EJB、JSP等J2EE技术发布之初，本书作者Rod Johnson就一直在使用这些技术，他对于这些技术的优劣利弊了如指掌。现在，通过这本书，你将可以面对面地分享他的专家经验。　　你将从本书学到……　　如何针对自己的应用程序找到最简单、最易维护的架构；在不使用EJB的情况下有效地管理事务；如何利用AOP和loC解决企业级软件开发中的常见问题；web层设计，以web层在设计良好的J2EE应用中的地位；J2EE应用中最有效的数据访问技术，包括JDBC、Hibernate和JDO；如何利用开源产品提升生产率、减少编码量；如何从设计层面上改善性能和可伸缩性。　　“传统的J2EE设计思路尤其是EJB日益让架构师和开发者们灰心丧气，我这本书正是为这些人而写的。本书将告诉读者，如何从现在开始用更清晰、更高效的方案去替代EJB，并开始迈向web应用的新时代。”　　这本书拥有一大堆“看点”。譬如说，它的作者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是一名企业Java架构师，在保险、电子商务和金融行业的信息化领域有丰富的经验。他是欧洲最大的门户网站之一的J2EE架构师，并且以顾问的身份参与了大量的项目。　　Rod在悉尼大学（University of Sydney）获得了音乐和计算机科学的学位。在回到软件开发领域之前，他还获得了音乐学的博士学位。他有相当深厚的C／C++技术背景，并且从Java和．J2EE发布之初就已经开始使用它们。他积极地参与到Java社群过程（JCP）之中，是JSR-154（SetMet 2.4）和JDO 2.0规范专家组的成员。自2000年以来，他参与写作了好几本J2EE方面的书籍，畅销书Expert One-on-One J2EE Design and Development（Wrox，2002年）便是出自他的笔下。

书籍目录

关于作者前言第1章　为什么要“J2EE Without EJB”聚光灯下的EJBEJB Under the SpotlightJ2EE还剩什么？站在十字路口的J2EE前行的路主旋律轻量级框架和容器我们还应该使用EJB吗？小结第2章　目标生产率问题传统J2EE方案解决生产率问题的办法提升生产率更好的办法OO业务需求的重要性经验过程的重要性小结第3章　各种架构架构性构件业务服务层向外部暴露业务对象数据访问层，或EIS层 40J2EE架构两种EJB架构两种非EJB架构J2EE架构实例“经典的”J2EE远程EJB架构本地EJB架构特制的非EJB架构“轻量级容器架构”：示例应用系统确定是否采用应用服务器小结第4章　简单性的红利复杂性的代价在J2EE应用系统中，导致复杂性产生的原因导致复杂性的架构性原因 66导致复杂性的文化性原因：一个依靠复杂性为生的产业复杂到什么地步就是过度了？简单还是幼稚？刚刚够好就行吗？变化的趋势总结第5章　EJB，五年间炒作和经验EJB和J2EE行业实践中的EJB一个过时的组件模型An Aging Component ModelJava语言的进步.NET的挑战Web Service敏捷方法学的兴起关于EJB目标的混淆从未出现的组件市场方兴未艾的新范式：AOPEJB, 我们真正需要什么？为什么无状态Session Bean如此流行？声明性事务管理远程调用集群线程管理EJB实例池资源池安全……第6章　轻量级容器与控制反转第7章　Spring框架简介第8章　基于AOP概念的声明性中间件第9章　事务管理第10章　持久化第11章　远程调用第12章　替换其它的EJB服务第13章　Web层设计第14章　单元测试与可测试性第15章　性能与可伸缩性第16章　示例应用系统第17章　结语索引

用户评论 (总计46条)

•   　　这不是一本开发细节的书，而是由替换EJB(2.0)所引发的对J2EE整体架构的一个解构，涵盖架构，开发，测试，无一不入木三分。虽是“without EJB"，但是EJB的”阴魂“却贯穿全书的始终，EJB的不足，EJB在特定领域的优势，EJB的替代……可以说，EJB构成了本书的基石和参照。另一方面，这又是一本不折不扣的Spring书。基本上对于Spring每一个特性的塑造，也是对EJB的一次推翻。但是这种推翻不是武断的，而是谨慎和雄辩的，尽管有些理由在我看来似是而非。
  　　全书就结构而言，大致可以分为以下几个部分：
  　　第一部分：1-5章，EJB的几宗罪。罗列了EJB缺乏的一些特质，及其这些特质在软件生产过程中的意义。
  　　第二部分：6-8章，Spring的核心特性。IOC(含依赖注入)和AOP的介绍和相关论述。
  　　第三部分：9-12章，使用Spring替换EJB。第二部分的延续，介绍如何利用Spring(尤其是IOC和AOP)实现EJB上有价值的一些服务(比如CMT)，以不依赖EJB容器的方式。
  　　第四部分：14-15章，过程与架构。其实这两章可以分开算，每一章都极具价值，尤其是第14章-单元测试和可测试性。
  　　就阅读而言，愚以为6，7，8，14章为必看，9-12章面向实践看，其余粗读即可。
•   　　当然最好能现看一下Rod Johnson的成名作：《Expert One-on-One J2EE Design and Development》——这本书是spring的前身。
  　　
  　　反正2本书都应该好好看看
•   　　当年看一份spring的文档，作者讲述了一个印度同事对此书的赞许，因此知道了这本书。 前几天同事（资深j2ee工程师） 问我有啥j2ee的书推荐的，我第一反应就是这本书。虽然自己还没看过，但是知道它的主旨，无论如何，都是好书，因为有了这本书才有了现在的很多概念
•   　　 俺就看的中文版，感觉浪费了很多时间，我知道 Rod Johnson 是大师级的人物，但感觉不太好。我还是想把有限的时间用到看如何应用框架的技术上，在此基础上讲解含义，我比较务实，推荐《精通Spring2.x--企业应用开发详解》 感觉不错，大家别骂我呀。没入行的不要评论我说的话，因为做项目时，已无时间看很多书，他们体会不到。
•   　　刊这本书是2年以前的事情了，本书是我阅读的所有技术书籍当中看的最仔细最认真的一本，也是我接触并应用spring+hibernate框架开发较长时间后读到的醍醐灌顶的感受效果。本书改变了我对软件架构的固有看法，使得像我这样的技术人员从更加高的角度去看待系统设计的问题，选择什么样的适合自身需要的软件开发架构模式，也清醒的意识到当初应用EJB2.0是多么不堪回首，拥有轻量级框架是一件多么美好的事情。
  　　总之，非常庆幸阅读了该书，值得珍藏！
•   　　名气大的很，让你想不看都觉得落伍的一本书。在没有用spring之前看，对作者的思想敬佩不已；在用过spring做一个项目后再看，仍获益良多。虽然它不像spring in action那样实用，然而知其然而知其所以然，此书又不可多得。
•   　　对于这本书最早的认识,是在一期程序员上透明推荐的"J2EE开发四书五经",在推荐这本书之前,是Sun的那本"Core J2EE Patterns",推荐语说到如果你看了without EJB,对于core patterns也就没有兴趣了.
  　　我并没有开发大型J2EE应用的经验,就目前来说我所写过的程序还都是一些Toy,我也没有真正的使用过EJB2.0,但是尽管我可能只是看懂了这本书45-60%左右,我还是感到学到了很多.并且每次翻阅都有新的收获.
  　　书中提倡的"循证架构",对于陷入J2EE泥潭中的J2EE开发专家们无疑具有极大的帮助.另外对于以Spring为核心的轻量级架构的推荐,也应该成为现在J2EE开发的首选.还有其它的很多令人受益的地方,比如:TDD等方法学.
  　　总之,我认为,谁不读这本书,谁就无法真正从繁杂的J2EE开发中脱离出来,也就无法保证开发出高效稳定的应用.
•   　　实际上我还没有读完这本书，而且我也没有看懂这本书，
  　　但是他确实给了我很多想法，或者叫灵感。
  　　这本书同样不推荐在不了解JAVA的情感下，去读这本书。
  　　可能又有人会觉得我故弄玄虚，其实只是想建议大家有写EJB程序的经验，至少写过几个例子，搞清楚了里面有几个XML文件，这些基础知识以后再就是有强烈的了解EJB的冲动，那么看这本书会让自己明白什么是EJB，如何用EJB。
  　　虽然本书介绍的是without EJB，但是看完本书我想对于一个程序设计师来说肯定会知道什么条件下使用EJB更合理，什么条件下还是别用这个令人烦恼的东西。
•   　　读这本书首先需要有相当的技术知识和实战经验。
  　　至于翻译问题，可能有，但是应该不会太离谱。
  　　最重要的是你要有实力明白书中语句的意义。
  　　有些词的翻译，本来就没有定论的，或者约定的。
  　　其实技术书籍的中文翻译，如果把一些关键词的中文后面加个括号，把原来的英文放进去，读者就能意识到了。
  　　
•   　　不管翻译的好坏，首先得尊重人家的劳动成果。
  　　我目前正在看这本书，个人感觉看看还是挺好的，可能是因为我技术实力太差的缘故。
•   　　尽管gigix在序言里说“还负责全书的文字修润”，但是如果首次的翻译已经不堪入目，那么再加修润无疑是愈行愈远，毫无帮助；何况从某些章节的翻译来看，根本就是脱离了英文原文在那儿做盲目的所谓修润（如果有的话）。而技术书籍的根本我个人以为“忠实原文，行文流畅”是至少应具备的。
  　　
  　　可惜，8个人参与翻译的这个中文版再次让人失望，尽管许多人对它的总体评价尚可。但是这么多人参与，无疑必会有鱼目混杂嫌疑，何况“国内J2EE技术圈里小有名气的人物”未必一定有过硬甚至基本的英文翻译水平。
  　　
  　　在顺畅的阅读之余，拿起英文原版书来对照一番吧，以便对中文的质量心里有底。我们不相信权威，更不应相信经过“翻译”的权威。看看第9／10章的翻译和原文对比，相信你会对此作出自己的判断。我只对比了第9章部分中英文（有两到三页），但是漏译、误译数量相当可观，绝非所谓勘误所能解决。
  　　
  　　（译者维护的勘误表）http://forum.javaeye.com/viewtopic.php?t=16269&postdays=0&postorder=asc&start=15&sid=2c8c875475c3436287ee8dd06ea38e89
  　　
  　　鉴于此，我有理由怀疑Robbin负责的全部翻译（即9／10章）。
  　　
  　　看来多人合作也要慎重啊。
  　　
  　　（尽管我初学J2EE，并无太多这方面的基础知识和技术积累，但看到9章第二段里的transaction demarcation译成“声明式事务”时，无论如何也无法容忍。）
  　　
  　　建议读过本书中文版或未开始读的朋友重读或直接阅读英文版9／10章。
  　　
  　　其它章节的翻译有待进一步观察。
  　　
  　　在讨论区里对第16章做了部分校对，也就五六页的样子，但是误译/待改进之处已数十计，没有心情再继续校对下去。这部分是 刘天北 负责翻译的。
  　　
  　　让我们记住JavaEye吧……不知道责编们是干什么的，无语。
  　　
  　　中文版还是要谨慎购买……
•   　　记得数年前，还是EJB2.0刚开始流行的年代。第一次在tss上看到这本书的介绍，当时功力尚浅，是EJB的狂热追随者，对这本“非主流”的书当然是嗤之以鼻了。
  　　
  　　时至今日，做过大大小小的项目已经过亿元，终于知道了这本书的价值。而他也已经从“非主流java书”变成了公认的“J2EE经典书”。这本书究竟好在哪里呢？他从最底层开始分析了J2EE尤其是EJB的一些弱点。因为分析的入情入理，作者现已成为EJB3.0的起草者之一。还应该说明一点，作者强调这本书不是写给初学者看的，个人认为，起码要有一个j2ee的项目经验，否则不推荐看这本书。
•   　　尽管没看过，但是很多朋友都说这书好，
  　　.net程序员也可以很好的借鉴其中的思想，
  　　不过e文实在太差，只好看中文的了。:-<
•   　　大致翻了一下样章第一章，看着挺累，或许和我之前从未接触J2EE有关，不过至少许多文法语法方面读起来有些稀奇古怪，影响阅读速度。怀疑直接看英文版也能有这样的速度。
  　　
  　　关于技术书籍，我同意侯捷先生的主张：能保留英文原文的尽量原样保留。
•   因为他有中文版了。看这书那就一个字累，你还别闲，愿意看英文书的人就不在乎多花这几小时翻翻词典，那叫一个犯贱。反正我不看英文的书，中文的也不错。 这是我msn上对此书评论 我评的。
•   当时年幼无知，呵呵
•   敢请楼主Breakthen@炉膛微火澄清“当时年幼无知”的含义？
  为何事隔一年后有如此感悟？难道有比该书更强大的关于JavaEE方面的书籍？望推荐~谢过~
•   本来想删除原来写的东西，后来觉得反正也是一种感想，就没有去动。这本书我已经在看第三遍了，总体来说每次看都有收获。有点看山还是山的感觉。
  书中虽然因为大师也是人，为了推荐他的SPRING，而在写作上和立论上加了些许技巧，但是这本书还是写得相对比较客观，书中也较为清晰地描述了如何不用EJB开发J2EE程序，并且对于EJB也进行了使用场合的定义，但是如果真想把这本书读成自己的书估计我还需要些时日。
  书中主要虽然介绍了J2EE Without EJB，但是并没有说明如果真的是企业级应用SPRING如何支持，但是毕竟成书时间是2003年，作者也无法预知未来的情况，如EJB3出来后，SPRING与EJB3的对比和集成。
  希望有人可以向我介绍一下他的SPRING新书，并且企盼他的新书。
•   恩，是大师的书，目前还看不太懂。
•   这是一本Spring的广告书，它成功地说服了我采用Spring为核心的轻量级架构去构建简单的企业信息系统，当然，如果你是Java fans的话。
•   dlee的第5／12章就目前看，或许比较忠实原文，尚可一看，不过在看过的p81－87中，仍有不少比较严重的误译。举例如下：
  1. E-P84-L2
  原文：Microsoft drew on expert knowledge of J2EE
  原译：...，微软从J2EE专家这里汲取了大量知识。...
  试译：...，微软汲取了大量成熟的J2EE知识。...
  2. E-P86-L13
  原文：Although they make sense only as components, we usually want to persist objects, not components.
  原译：entity bean仅仅作为组件才有意义：但我们通常需要持久化的是对象，而不是组件。
  试译：把它们（entity bean）看作组件才说得通，但是我们通常愿意坚称其为对象，而非组件。
  3. E-P87-L9 不可容忍！整段译错
  原文：Interestingly, the only characteristic of a component that appears in the literature on component software that the practitioners didn’t cite was that components are likely to be sourced from third parties; this is one area in which component theory hasn’t been realized in practice.
  原译：有趣的是，组件的另一个重要特征似乎从未在相关著作中出现过：组件可能是由第三方编写的。看起来，这是组件理论尚未认识到的一个实践领域。
  试译：有趣的是，这些同事（注：上文提到作者对其同事作了一个调查，指的就是参与调查人员）唯一没有指出但在组件软件相关文献中出现过的一个特征是：组件可以是由第三方编写的。看来，这是组件理论在实践中尚未涉足（realized：实现，译成：认识，知道？似乎也可，作者在这儿有戏谑之意）的唯一一块地方了。
•   呵呵，苛求了，其实能翻译到现有程度，也已经是相当不错了，毕竟，在被国内那些译版书摧残之后，这本无论如何我也要给它个五星。
  目前，这本书我还只翻到事物那章。说“翻到”是因为只用了一个晚上（由8点到凌晨3点吧），显然囫囵吞枣。不过此遍过滤，好处在于理清了一些模糊的概念，另外印证了一下自己的一些想法，有此收获我已知足，毕竟很久没有花这么长时间看一本书了。
  也正因为翻的太快，导致的直接后果是楼主说的那些我几乎都没有关注到。 不能不佩服，楼主看书的仔细^_^
•   偶也给自己勘误一下：
  事务而非事物^_^
  都是拼音惹的祸
•   只是因为发现太多的漏译误译才对它关注起来，当然一方面可能是出于自己尚在初学阶段，所以也才更加苛求。不过就我发现的错误来看，这本中文版的翻译糟糕的可以，至于翻译“流畅”的部分，英文原文也很简单，也没什么可赞赏的。
  我还是建议你再看英文版。
•   本书论坛里有部分章节的误译/漏译。如果可能尽量看英文版。
  http://www.douban.com/subject/1426848/
•   2. E-P86-L13
  　　原文：Although they make sense only as components, we usually want to persist objects, not components.
  　　
  　　原译：entity bean仅仅作为组件才有意义：但我们通常需要持久化的是对象，而不是组件。
  　　试译：把它们（entity bean）看作组件才说得通，但是我们通常愿意坚称其为对象，而非组件。
  你的试译压根就是乱译，不知道你有没有开发过j2ee应用。根本没有理解persist的意义，就只从字面上翻译。
  还是尊重别人原译吧。
•   我并非不知道“持久化”这一意思，只是从整个句子前后来考虑。是的，我从来没开发过j2ee应用，这并不能说明什么问题。
•   LEE，我一直很想确认这句话怎么译。
  如果仅把persist译成持久化，我看不懂这句话的意思。请赐教:)
•   2. E-P86-L13 这里我认为leal的翻译是正确的
•   也许应该翻译成“通常我们要持久化的是一个个对象，而不是组件本身”
•   Persist 在 计算机专业英语里面 是持久化的意思 不是坚持
•   虽然事隔多年，但是在专业词汇都没搞懂就乱评书的翻译，实在看不过去了。
•   同楼上，太看不过去了。
•   这两天又拿出来翻了一下，一遍看正文一遍要对着附录索引找可能的英文单词，太累了，术语被翻译的无厘头。
•   = =我去，你们先学下相关技术再来吐槽好不好...
•   受不了，不懂专业词汇的人乱评
•   试译：把它们（entity bean）看作组件才说得通，但是我们通常愿意坚称其为对象，而非组件。....行吧，您坚持吧...
•   结合实体bean的设计目标，这个persist 确实不该理解成坚持。
  作者如果想说“坚持”，我觉得一定不会用这个词。
•   "起码要有一个j2ee的项目经验",不确切,不是在于一个或者几个,也不在于做过的项目是否"过亿元",而且真正对J2EE的理解...
•   确实不是很确切，但是总得有个客观的标准吧，而不是主观的说“真正理解”:)
  希望和你交流，共同提高。
•   衡量一个软件工程师水平的客观标准大致是：学历、工作年限、工作公司、项目经历。一个比一个重要。
  这里是指职业软件工程师，当然不排除高中生奇才出现的才能。是不是可以这么说，客观标准都满足的工程师（比如，重点大学计算机专业本科，从事软件业3年以上，服务于CMMI5级的公司，项目的客户是世界50强等等，这些都是客观标准，不只骑士是否满意），肯定是个合格的软件工程师。反之则不一定。
  从软件行业角度说，管理者最需要的是可度量的信息（>=CMMI4）...此话题太长，打住:)
•   青胜蓝一定是个合格的软件工程师啦。
  :P
•   客观标准都满足的工程师（比如，重点大学计算机专业本科，从事软件业3年以上，服务于CMMI5级的公司，项目的客户是世界50强等等，这些都是客观标准
  学历代表什么，代表你多花了些钱和时间在校园里面罢了，如果你多花时间在项目上才是正确的方向。
  工作年限代表什么，代表你的公司多花了钱付你工资，如果你多花点时间思考才是正确的方向。
  工作公司代表什么，那只是提供一张桌子和一张椅子的地方。
  项目经历有时什么，那只代表你是项目组的成员，不代表你的贡献。
•   看一半又放下了。。。
•   的确是十分赖看，Java，Ejb什么的我也不懂，但是的确是相当经典，IOC，AOP，TDD，简单但实用
•   我可是一气呵成，一口气看完了，呵呵。
  这本书的确需要有过比较深厚的java开发才好读，不是针对j2ee初学者的。另外可以先从作者的上一本书"Expert One-on-One J2EE Design and Development"先入手。这本书奠定了spring的理论和发展基础。
  应该来说，这本书翻译得非常好了！