随笔-193  评论-715  文章-1  trackbacks-0

  在我阅读此书之前,我应该总结一下目前在 J2EE 方面所具有的基础知识。在我看来, J2EE 是一个极其庞大的系统架构,对于 J2EE 有一些初步的认识,也做过一些基于此架构的小型或中小型项目,比如基于此技术架构的网站,一些应用系统等。 J2EE 包括以下部分:
  
  对于
EJB ,我仅仅只是知道其基本概念,从未有过深入的学习和研究,也就是说有一个肤浅的认识。而对于 IoC AOP 则有一定的了解,因为之前在学习 Spring 的时候有过一些深入的学习,但是对于 AOP 的理解是远远不够的。

好了,开始言归正传,真正开始谈谈一些我自己的肤浅观点(甚至是错误的观点)。

 

书中谈到“ J2EE 应用项目至少和从前的非 J2EE 项目一样容易失败――如果不是更容易失败的话”( page 4 ),我认为一个项目的失败与该项目采用何种框架和技术有太大的关系,在这个时代,对于架构和技术的选择有很多,而更关键的因素可能得从软件项目管理方面来衡量,从所周知,一个项目采用何种架构和细节性的技术只是项目管理的一个小部分。“而在 J2EE 遭遇失败的场景中, EJB 通常都扮演着重要的角色”( page 4 ),这样说似乎也显得很牵强。

书中再次强调“最成功的标准都是从实践中发展出来的” (page 5) ,最显著的例子莫过于 OSI TCP/IP 之间的关系。

本书的主旋律主要包括以下部分:

1 、简单

我常常在工作中就把一些问题看得较复杂,因为总觉得这不是一件坏事,考虑到一个问题的复杂性并认真想清楚此问题的各个方面,在解决这个问题的时候相对来说就会简单一些,但是这样也确实会带来诸多问题,如软件成本的核算,我就曾因此在一个客户需求并不高的情况下把问题复杂化了,导致了那个方案的失败。上次我就是犯了“提前叫客户掏钱购买的复杂架构”( page 6 )这样的错误。“这种想法有两个问题:首先,是否让系统变得如此复杂不应该由作为架构师和开发者的我们来决定,因为买单的人不是我们;其次,即便系统最终变得如此复杂,我们又怎么知道一开始将它们考虑进来就能节约成本呢?说不定,等到有需求的时候再修改架构还会更节约呢。”( page 6

书中主要从技术层面上讨论了这个问题,如数据库的分布,多种客户端等。对于问题的解决我们应该更切合实际一点,不要沉溺于一些不切实际的想象。

“XP 的核心教义之一就是:很多时候,越是节约成本,就越能开发出高质量的软件;不要试图预先解决所有能想到的问题。 page 6

“使 J2EE 项目具备架构重构能力的关键在于:遵循良好的 OO 设计法则, 并且始终针对接口编程、而非针对类编程;将EJB之类的技术隐藏在普通Java对象背后。 ”( page 7

2 、生产率

虽然我没有真正的用 EJB 来开发过任何项目,但根据我对 EJB 的了解来看, EJB 在生产效率方面确实存在着很大的问题。

3 OO

以前我在设计一个对象的时候,根本没有认真的考虑过某一个对象是否真正的合理,这个需要在以后的设计中得以重视。

4 、需求至上

J2EE 的开发者们仅仅因为他们的技术选择――而不是客户的需求――就耗费了更多的精力。” (page 8)

5 、经验过程

经验对于一个软件开发者来说是极其重要的,很多问题只有你在具体的实施过程中才会发生,但是我从不拿一个人参加工作的时间长短来衡量一个人的经验是否丰富。

书中提到的循证医学( EBM )到是一件很有意思的事情,我觉得值得我们中国的医生好好的学习和思考一下(题外话)。

6 、可测试性

对于软件测试,我其实并没有深入的认识,我一直都处在开发的前沿,没有更多的机会和时间来深入研究测试,其实软件测试是一门很值得研究的学问。就拿腾讯的程序来说,其出错的机率远远高于其它软件,这是人的共知的,我想这也是腾讯所需要重视的。

 

关于轻量级框架和容器,我一直在关注 Spring PicoContainer Nanning 等。

 

书中讲到的“帕累托法则( 80/20 法则,或 90/10 法则)”的确可以作为我们在项目实施过程中考虑该如何解决问题的一个衡量标准。即“花比较少的力气就可以解决大部分的问题,而要解决剩下的少部分问题则需要多得多的努力。”( page 11 )这教会了我们如何在项目中做适当的取舍(包括软件架构的取舍和需求的取舍,当然很多时候需求是不能改变的)。

EJB 在那些真正需要对象的分布应用方面仍是上佳之选,同时在需要大量使用异步消息的应用中,也是不错的选择,同时, EJB 在金融中间件的应用中,也能为项目提供价值。

本书所推行的思想就是, EJB 并不是要被我们完全抛弃,只是在一些没有必要使用 EJB 的项目中,我们可以如何找到更好,更简单,更具生产率的替代方案。

同时需要澄清的一个误解是: EJB 一直被视为 J2EE 平台的核心。这种观点把 EJB 的地位看得太重了一些。

书中说“还有强大的政治因素(而非技术因素)促使人们使用 EJB ”( page 12 ),对于此句中的“政治因素”不知所指。是说的来自 Java 官方(即 SUN )的因素吗?

posted on 2005-11-29 17:19 Robin's Programming World 阅读(5538) 评论(8)  编辑  收藏 所属分类: Java读书

评论:
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-11-30 13:37 | space
put it to trash bin;  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-11-30 14:18 | nighthawk
en,Robin?javaeye的?  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-11-30 15:01 | Robin's Java World
我是Robin不是Robbin.

本来这是我自己的读书笔记,所以水平难免极低,不对之处请大家原谅!
希望大家能给我一些中肯的意见。

谢谢!  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-11-30 15:43 | 笨笨狗
这本书我也看了,说白了就是sping的广告手册,感觉作者带有强烈的个人色彩,权当补充知识得了,不足全信  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-11-30 16:31 | Robin's Java World
关于读书,肯定应该持“不可不信书,也不可全信书”的态度。

其实这本书在架构方面有些知识还是值得一看的。

谢谢!  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2005-12-01 22:00 | mkclawhammer
书中多次提到了“政治因素”,我想可能是指JCP,这个机构由各大厂商参与,出于自身的利益而互相争夺标准,阻碍了java规范的快速演化。对“政治因素”的不满在不少老外们写的书中都可以感觉的到。  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2006-04-26 14:21 | pc
这本书还好吧  回复  更多评论
  
# re: 《Expert one-on-one J2EE Development without EJB 中文版》读书笔记(一) 2006-06-09 14:32 | Robin's Java World
应该说这本书不是专门讲具体技术的,理解其中的思想才是关键。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: