从EJB饱受抨击想到的

以前我听不止一个人对Entity Bean抱以否定的态度,而J2EE development without EJB...在这本书里,至少有一半的篇章对EJB抱以强烈的抨击和讽刺.讽刺的焦点集中在:

1. 架构过分复杂.

2.提供了不必要的远程调用机制.

3.偏离了OO的设计原则

4.Entity Bean只是一个数据库映象层,不能提供真正的ORM功能.

 

作者在书中告诉人们:实践是检验真理的唯一标准.而架构师想象出来的完美架构往往不是程序员真正想要的,和合适的东西. 由此我想到IBM制造出来的众多架构,Activity centered, Composite application, ESB,..., 会不会也有这种"空中楼阁"的成分? 这可能也是IBM Workplace叫好不叫座的原因之一吧. 比如Workplace系列应用都有一个共通的特点,就是支持离线应用.一个例子是邮箱,可以白天在公司里收信,晚上回家离线阅读. 把这种模式推而广之,就形成了离线应用的模式. 可以把以前部署在server上的web应用,portlet application完全搬到client端,在本地搭一个嵌入式数据库.离线时可以用浏览器连接本地的web app,而online时完成数据库同步. 想法很好,但是不知道有什么具体的业务(除了邮箱)会有这种需求. 看了看新闻发现Microsoft 也在支持这种东西....

 

来自without EJB中对架构师的批判是很激烈的.这种批判来自信仰XP哲学的程序员对传统程序设计思想的挑战. 但是我有如下感觉:XP哲学基于的经验,大都来源于XP作者们的对精巧的小型项目的实践.但是现实生活中的确存在着需要2000-3000程序员合作完成的,渗透着极其复杂的思想,因而需要很多架构在里面的项目. TDD是个好东西,但是它里面没有告诉我怎么把一个project拆成部件,让一个200人的team去分别完成每个部件,然后集成. 我们只能依赖传统的OOP和架构师的努力. 我看到作者在书里暗示着他对Rational Rose的态度,我觉得这种态度是有失偏颇的.送一句老罗语录: 年轻人,总是把创作的冲动当成创作的才能...

 

评论

1 楼 robbin 2006-11-25  

传统软件方法论的出发点是：
通过工程学的方法有机组织开发团队和分工，提高人的群体处理复杂问题的能力，来match大型软件的高度复杂性。

敏捷软件方法论的出发点是：
降低大型软件本身的复杂性，分解为简单的单纯复杂性问题，来match人的处理问题的能力。

引用

但是现实生活中的确存在着需要2000-3000程序员合作完成的,渗透着极其复杂的思想,因而需要很多架构在里面的项目

能不能换个思路，考虑怎么才能分解这种大项目成为需要小项目，而不需要那么多程序员的协作呢？