shipatrioc http://www.jdon.com Nov 30, 2004 8:55 PM 回复
本人不太聪明,学了两年java却越学越糊涂.看了很多东西,不但大脑里没有头绪,反而有种走火入魔的感觉.开始做项目就用ejb呀,那时刚毕业,好像 ejb是j2ee的代名词,但开发的系统却很慢,我还老诧异,怎么还没有我们用CGI开发的速度块,CGI是多进程,但Servlet可是多线程,不是一个重量级的呀?然后就有人站出来,历数entity bean的十大罪状.然后好像Hibernate,JDO这些名词比较吸引人的眼球.再以后,我的老师从国外回来专门讲了一堂课,专门提了Spring, 我再到大大小小的论坛去看,乖乖,这不是Spring的天下了!就去学吧,看了一段时间发现Spring也不是万能的,它没有提供分布式部署的方案呀,还是要结合ejb来实现分布式系统.然后忽然发现一本书使我一度欣喜若狂,就是Spring作者的那本Without Ejb,看了一些,好像大意是让我们理性的使用ejb,还说80%的系统是不需要分布式的,然后我又迷惑了,我们开发的系统到底在这80%里面呢,还是在另外20%里面.书我没有坚持看下去,因为大脑开始闹革命了.唉,糊里糊涂的写糊里糊涂的java代码!又稀里糊涂罗嗦了这么多,大家知道我在说什么吧 :)看题目就知道了,我发发牢骚别见怪!
Re: 项目规模的界定!
发表时间: Dec 1, 2004 10:26 AM
回复
发表人:
banq 发表文章: 3774 / 来 自: 上海 / 注册时间: 2002-08
我们知道，需求是软件之母，只有人类的实践需求，才会有软件，才促进软件发展，如果有个人试图对人类的需求进行指手画脚，只可能有两种人：1.别有用心的人；2.傻子。
这个人试图指出我们实践中的80%的系统是不需要XXX，进行这样的断言，已经超出用极端两个字，我提倡技术上可以用极端，例如，你可以说，Spring技术设计完美无缺，我无可非议，因为技术人员谈技术，极端一些是正常。
但是，技术人员试图对技术以外的需求指手画脚，不论他是谁，我是极端反感，并一定骂他狗血碰头，不管他是什么世界名家和妄图成名之类的鸡犬之徒。
Re: 项目规模的界定!
发表时间: Dec 1, 2004 11:45 AM
回复
发表人:
shipatrioc 发表文章: 6 / 注册时间: 2003-08
首先谢谢banq的回复,不过说实在的,看了你的回帖我还以为我说错了什么话,还好话都是别人说的,我转一下而已.这个论坛我来了不少,也在其中的争辩中学到了不少东西.但有一个感觉是这里的人好像火气比较浓(可能技术上有所专长的人都这样吧),所以也战战兢兢不敢发帖子呀,呵呵.帖子既然发出来了,我还是想听一下大家的意见.再把需求描述一下吧:中小型的项目使用web服务器就已足够,可是大规模的项目使用ejb或者使用web service,或直接调用rmi能使项目具有更大的弹性,但由此也带来很多开发和性能上的代价.那么我们进行项目开发时,项目规模的这个度怎么来界定?
我在csdn上也发了相同的帖子,有兴趣的可以去捧捧场!先谢了!
http://community.csdn.net/Expert/topic/3603/3603919.xml?temp=5.256289E-02
Re: 项目规模的界定!
发表时间: Dec 1, 2004 12:46 PM
回复
发表人:
ljshan 发表文章: 8 / 注册时间: 2004-11
干技术的似乎总觉得“流行就是好的”，ejb刚出来时，一窝蜂似地用ejb开发，不管系统有多大多小，只要用上ejb就觉得系统会多么多么好，心里多么踏实；后来慢慢地觉得ejb这个那个得缺点，被许多人瞧得一无是处，继而出现轻量型容器的流行，spring，aop...,或许将来又会批判light- weight的这个那个缺点...流行风发生在技术人员身上尚可，可是发生在管理人员身上可就惨了！其实我认为ejb固然好，light-weight container也不赖（light-weight不也是站在ejb技术的肩膀上发展起来的吗？），关键看你选择的软件技术与你的需求（包括功能实现和系统性的非功能需求）是不是对路，试想如果写一个guest book是一个独立的项目的话，有必要用ejb，light-weight吗？固然，就一般的系统而言，大多数人会采用light-weight container的做法，这是事实，但是大家都明白80/20的法则，如果把项目作为考查对象的话，可能你的项目就是20那一部分，规则不是也有例外吗。罗嗦这么多，总之前提是不能脱离项目本身的需求，另外还要考虑软件的实现和维护成本，是从工程的角度考虑，而不只是从技术层面上考虑。
Re: 项目规模的界定!
发表时间: Dec 1, 2004 5:22 PM
回复
发表人:
shipatrioc 发表文章: 6 / 注册时间: 2003-08
谢谢ljshan 的关注,我也明白其实需求是第一位的,项目能做好,用户满意是第一位的,一个项目的开发选用什么工具要考虑很多因素,比如硬件,资金,开发人员的技术水平,我在这讨论的其实是一个很简单的问题,可能我的表述还不是很确切.简单的说,算是做个调查,也算是做个交流,平常大家开发都选用什么框架,基于这样的框架能满足多少人同时访问,速度如何?
Re: 项目规模的界定!
发表时间: Dec 2, 2004 9:15 AM
回复
发表人:
banq 发表文章: 3774 / 来 自: 上海 / 注册时间: 2002-08
shipatrioc 误会了我的意思，我是炮鸿那个without EJB的作者，他作为一个专业人士，竟然对另外一个领域：需求，进行断言，更有甚者，他后面所有的逻辑都是依赖这个站不住脚跟的观点。
如果需求能够断言，那么银弹就诞生了，问题是：需求是永远变化的，你很难对你的客户需求进行断言，你唯一要做的就是:做好适应变化的准备。
以某个小企业的进销存系统为例子，今天给你做的可能是一个小系统，不需要什么分布式等等，但是企业出口获利，中国企业的规模膨胀速度是世界有目共睹的，当你给他做了一个不具备伸缩性的系统后，这个系统就可能成为阻碍他发展的绊脚石，你要适应他发展，就要更改架构，重写编写？
所幸，Spring提供了依赖EJB的可伸缩性，这是他的明智之处，但是如果你提出without EJB，那么你的存在价值在哪里，仅仅靠一句断言：80%不需要分布式EJB？
Re: 项目规模的界定!
发表时间: Dec 2, 2004 9:46 AM
回复
发表人:
banq 发表文章: 3774 / 来 自: 上海 / 注册时间: 2002-08
就主要问题发表我的个人看法：
"中小型的项目使用web服务器就已足够,可是大规模的项目使用ejb或者使用web service,或直接调用rmi能使项目具有更大的弹性,但由此也带来很多开发和性能上的代价.那么我们进行项目开发时,项目规模的这个度怎么来界定?
"
首先，“带来很多开发和性能上的代价”是一个误区，也是一些人反复诋毁EJB的结果，我在使用JdonSD框架和JBuilder等高级开发工具情况下，一个十个模型的小系统，我一个人一天将其增删改查的所有功能实现，具体可参见我的estore源码。http://www.jdon.com/my/train/controllAction.do
所以，要形成在EJB上快速地开发模式，需要实践或外界培训指导，软件本身就是一个专业的东西，如果还期望象VB、Delphi那样的只需要几个毕业生就能搞定，那么软件就不是一个高技术行业。如果你采取成熟的EJB开发模式，那么你就可以形成规模开发，甚至形成蓝领工人的产业格局。
我曾经教过印度NIIT的J2EE课程，这个课程就是主要讲EJB，在印度，能够进入NIIT学完这个课程，马上就能够出国，这是印度的蓝领产业的一个宿影。
关于EJB性能上的代价，这更是误区，在我的书籍和资料中，我一直引用JBoss的创始人的一句话：“EJB的优点首先是性能的优点”，如果你认为EJB有性能问题，就说明你对EJB多么外行，这个问题在我以前帖子中已经反复声明，http://www.jdon.com/my/是使用EJB开发的，你觉得性能低吗？与其道听途说，自己使用Jmeter来测试一个EJB系统的性能。
也有人说，EJB是开发成本问题，这又是一句谎言，开发成本永远是你程序员本身素质问题，也许你适合去做蓝领程序员，但是你在做模式、架构的规划和编程，速度效率能不低吗？这是EJB开发成本问题吗？
所以项目规模没有度的问题，有的只是技术之外的东西，如果你的项目你不再做维护，你不以其为生，那么你不必使用伸缩性强的架构，当然，如果采取就更好，说明你的软件质量更高，但是你必须能够低成本提供这些高质量系统，如果你达不到，就用Jsp+数据库，或者用.NET不错。
除以上一个情况，其余我都推荐你使用可伸缩性架构的系统，当然，可伸缩性的架构不只是性能可伸缩，你的设计也需要这样，比如，你的用户授权体系需要是树形结构的，而不是flat，扁平的等等。
在Spring 出现之前，EJB是一个唯一的选择，但是Spring目前提供了一个中间选择，因为Spring提供依赖EJB的可伸缩性，所以，你开始使用 SPring，以后可以需要使用EJB时，将Spring的business Object配置到EJB容器中实现就可以。
如果你不觉得 Spring复杂，开始建议你使用Spring，但是千万别受“without EJB”谣惑，否则你又不知道路在何方，这也是大多数人现在困惑的地方，我在程序员上发表了“混乱的Java世界”就是表明了程序员的这种困惑，可惜这样实际的问题遭受了程序员杂志的封杀，我也再不会给程序员杂志写稿了。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 10:29 AM
回复
发表人:
banq 发表文章: 3774 / 来 自: 上海 / 注册时间: 2002-08
上贴观点并非针对楼主，我是借题发挥，对一种普遍观点发表一些看法，仅仅供参考，可能有些极端观点，也请注意批判性地看待。
欢迎每个人发表观点，对事不对人是Jdon论坛争论的宗旨，因此，不管什么人都可以理直气壮发表观点，我以前说过“太阳死了”意思是这里没有什么所谓技术权威，而是争论，有理性的真正的争论，初次发言者也无需战战兢兢，版砖随时会砸来，但这不能阻碍我发言的自由，我要自信。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 4:33 PM
回复
发表人:
nekesai 发表文章: 25 / 注册时间: 2004-10
哈哈，BANQ说的好，佩服。真正对事物的本质了解了才有此大作,^_^。对，需求是永远都没有停止的时候，否则这个世界就停止不前了(这句话需要一定的哲学底蕴哦)。我们客户的业务极有可能因为市场也爆炸性增长。我就曾经遇到过这样的项目，原来客户的业务只停留在国内，后来却延伸到了日本和欧洲，一下子整个系统负载的问题出来，而且原来因为国内数据量还可以承受，采用了集中式（就一台应用服务器),就不同省份的业务直接连到该服务器进行业务处理都可以，而不是各省有各省的应用服务器，当时采用jstatemachine(是一个开源的)+Dao+vo以及oscache和一些pool。但现在日本和欧洲的业务增加就导致了数据量大增，以及整个用户也都上去了，呵呵，这时候日本和欧洲都需要各自的服务器，然后某个时间把数据进行数据传输，但业务流程有跨服务器的而且数据库也是和应用服务器一对一的配置。呵呵大家猜，有什么问题了，就是banq所说的伸缩性，还有事务是global的而不是local的，呵呵原来的系统要改为Ejb了，一点办法都没有，不会告诉我使用RMI吧，如果使用RMI的话，全局事务怎么办，你不会又要告诉我使用tryx或者jtom 吧，我的天啊，那你去写一个EJB容器好了，在说我也怕自己写出来的稳定性和性能又问题，虽然我自个认为自己的技术很好哦。现在完全改为持久层用EJB 了，还有很多头疼的pool也不管了，^_^。要是一开始就选用EJB的话就好了。
好了，说到这，又些人就会问我了，有多少的系统的业务像你们客户全球性的，呵呵，我只能说你不懂EJB。从一开始使用ejb，就是利用它的伸缩性以及容器的一些固有的服务，也说明了你一开始就为客户负责，考虑到将来的变化，不止是业务变化。因为Ejb是分布式业务组件，什么是分步式，就是说它可以在任何的一个地方参与计算，这样就“完全”的可以复用了。知道现在复用的境界式什么吗？不要告诉我是类复用哦，听好了是业务服用。就是说如果是一个订单业务，现在的复用层次是如何去复用这样业务，而不是订单里面的某个类哦,也就是我们要建立面向服务架构（SOA）的方法策略。呵呵，EJB是分步式业务组件（千万不要只把EJB理解成是一个域模型，因为那只是entity Bean,还有sessionBean呢,对EJB要理解好），如果你另外一个应用需要订单业务，那直接从你的应用中调用它好了。
现在我谈谈别人说什么EBJ难开发的问题，老实说EJB不能开发，它唯一一个难点是测试不方便，但现在的JBUILDER支持remote debug是没有问题的。如果公司或你的小组有一套开发框架，如，表现层用jsp+struts,控制层和应用层使用struts+command模式，服务层使用command+facade,持久层就Dao。Dao里面是jdbc也好，还是hibernate也好，还是EJb都没关系。
那么居于这个框架你写一个生成器，当然可以使用xdoclet,velocity等。
你开发什么都不难。如果没有的话你就开发struts+hibernate都很麻烦。
好了，我当然不是EJB的传播者，也不是其他方案的反对者，我所要说的是，我们要深刻理解事物的本质的前提下去发言去选择，这样的话你的风险就降到最低，也为用户负责。如果一个用户就只投资10万块上一个小的CRM系统，你也给它上EJB，10万连买个 weblogci都有问题，你说怎么办，当然是不要EJB了，但这个要说明好。但绝对不是因为其他的方案什么性能比EJB好，开发成本底我才不用EJB。
其实国内是不懂很多本质的东西，还有对EJB也了解不深，有些人连RMI是什么都不完全清楚，什么是分布式等等，为什么要有分布式等这些东西就瞎说，说白了就跟风。
最后我可以告诉大家，即使用Struts+ejb还是struts+dao+jdbc或hibernate我也可以一个小时内把整个系统原型构建出来（包含基本的ciud和查询以及整个系统构架），这基本跟你采取ejb不ejb是没有关系的。
软件技术的风险占的比率是整个风险的很小一部分。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 12:14 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
无论技术在怎么样变化，他有多先进，但人类的思维总是不能被很好的描述的。同时，在项目开发的过程只能看到目前和可能的未来，无法穷尽所有的变化。所以在设计和开发时应该保持项目的演进，让项目“活”着。至于技术应该把他当作一种受保护的资源，区别对待。
这里针对Java和.Ｎet的就是最好的例子，为什么有人总是再说谁是谁非呢？因为他们陷入了技术的旋涡！没有看清一些事实罢了！或者说他们站在一个高度去＂盲目＂地指挥...
Re: 项目规模的界定!
发表时间: Dec 2, 2004 12:56 PM
回复
发表人:
banq 发表文章: 3774 / 来 自: 上海 / 注册时间: 2002-08
Kidwish 的让项目“活”着观点也是我要表达的意思，我认为强调可伸缩性是让项目“活”着的一个好建议。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 4:47 PM
回复
发表人:
nekesai 发表文章: 25 / 注册时间: 2004-10
Kidwish 提出的问题很好，只是我很希望他能提出解决问题的方法。
在这里我们更关心的是如何让才能让项目“活”着，也是我们在考虑项目规模如何界定的问题，因为它的“活”，所以这个需求导致的项目scope是模糊的，并且一直模糊下去，否则就没有“活”着。但我们就从技术角度来怎么保证这个项目的“活”导致的膨胀呢，那就是伸缩性。
不要说在这里我还需要去解释什么是伸缩性吧，伸缩性不只是性能哦，在技术性上保证了伸缩性那就很容易适应业务的变化，甚至其他网络和硬件上的物理变化。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 4:54 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
“我认为强调可伸缩性是让项目“活”着的一个好建议。”
我认为确切地说应该是架构的可伸缩性。伸缩性何来？大部分人可能考虑的是系统功能性方面的架构因素，但是这是不够的，往往忽略了非功能性的考虑，诸如质量，维护，技能，人员等。所以好的架构不是鼓吹出来的：什么轻量级的容器，EJB负担之类。是应该来自对问题域的理解，寻求方案而来。
技术是要关注的，我始终觉得一个好的设计人员，应该了解各类技术，但是不是偏执一个“完美”的设计！
Re: 项目规模的界定!
发表时间: Dec 2, 2004 5:02 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
“Kidwish 提出的问题很好，只是我很希望他能提出解决问题的方法。”
我也在寻找，但是要知道这是多么困难。就如抽象一样...
但是，我已经发现有些行之有效的方法论的东西。我的观点是取长补短，灵活驾御。
好的架构思想很多，架构模式方面的书籍也很多。要寻求好的架构，我认为来源就在自己手里--需求。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 5:06 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
还有一点我觉得要注意，软件项目中的＂阴影＂，就是不断膨胀的系统和功能！－－＂阴影扩散＂
我的想法是保持增长，但是要注意大粒度。
ＰＳ：话题有些远了....
Re: 项目规模的界定!
发表时间: Dec 2, 2004 6:04 PM
回复
发表人:
nekesai 发表文章: 25 / 注册时间: 2004-10
》》》我认为确切地说应该是架构的可伸缩性。伸缩性何来？大部分人可能考虑的是系统功能性方面的架构因素，但是这是不够的，往往忽略了非功能性的考虑，诸如质量，维护，技能，人员等。所以好的架构不是鼓吹出来的：什么轻量级的容器，EJB负担之类。是应该来自对问题域的理解，寻求方案而来。
》》》》》
架构的伸缩性能提供保证对需求变化良好的解决手段，但对需求变化的管理和控制是保证需求变化的有序和粒度以及反回来影响需求变化的频度，这是从管理方向来说。但需求的变化跟什么质量，维护，技能，人员有什么关系，解决需求的变化应该说去处理需求的变化跟这些又有什么关系，基本上没有关系。
应该这样说，需求的变化基本是客户提出来的，那你就得做。你要做吧，那你就先要进行需求变更风险评估，结果基本是做的，那做就要要求系统有良好的伸缩 性来适应。
并且如果你偏要比较Ejb以及它的容器和其他的轻量级容器就伸缩性来说，那ejb毫无疑问是占上风的。如果什么都不要考虑，就考虑如何去适应客户业务的变化和膨胀，那当然ejb是最佳。
其他管理方向的手段那是另外讨论的问题。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 8:49 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
"架构的伸缩性能提供保证对需求变化良好的解决手段，但对需求变化的管理和控制是保证需求变化的有序和粒度以及反回来影响需求变化的频度，这是从管理方向来说。但需求的变化跟什么质量，维护，技能，人员有什么关系，解决需求的变化应该说去处理需求的变化跟这些又有什么关系，基本上没有关系。
应该这样说，需求的变化基本是客户提出来的，那你就得做。你要做吧，那你就先要进行需求变更风险评估，结果基本是做的，那做就要要求系统有良好的伸缩 性来适应。"
没有哪个架构能很好的保证或满足需求变化，更不能满足系统的膨胀。最贴切地就是刚设计好的架构，再开发后马上就变了型。因为架构是需求下的产物，要一个定型的架构去适应频繁的需求变化是困难的，应该让需求变化来催生架构的改进。因为我们欢迎需求变化！这也是XP/敏捷所提倡的。如果架构去反适应需求的变化，最后只能是不能满足需求。
还有我并没有说质量，维护，技能，人员和需求有什么关系，我只是把他们定为“架构因素”，从而做出某种“架构抉择”。
Re: 项目规模的界定!
发表时间: Dec 2, 2004 10:18 PM
回复
发表人:
nekesai 发表文章: 25 / 注册时间: 2004-10
to
to kidwish:
< <<<<没有哪个架构能很好的保证或满足需求变化，更不能满足系统的膨胀。最贴切地就是刚设计好的架构，再开发后马上就变了型。因为架构是需求下的产物，要一个定型的架构去适应频繁的需求变化是困难的，应该让需求变化来催生架构的改进。因为我们欢迎需求变化！这也是XP/敏捷所提倡的。如果架构去反适应需求的变化，最后只能是不能满足需求。
还有我并没有说质量，维护，技能，人员和需求有什么关系，我只是把他们定为“架构因素”，从而做出某种“架构抉择”。
>>>>>>>>>>>>
架构说跟我常合作的ejb,ejb是叫做业务组件，别理解错它了，它不只是域模型，什么是业务组件，就是具有相对独立的业务逻辑封装的实体，具体一点我可以把一个订单业务用一个sessionBean来表达，外面客户端经过service 接口来调用我这个业务，如果订单业务改变了（业务逻辑变化，是需求变化的一种），我的主人可以只要修改我这个sessionBean就可以了，客户端不要做任何改动，如果有新的业务要增加，我的主人就给我添加一个sessionBean兄弟好了(需求增加)，如果有一个新的业务兄弟A需要在我的订单业务逻辑过程中进行
先处理，如果A也是我的EJB兄弟的话，只要在我的逻辑中对他进行调用就可以了（业务逻辑变化，需求增加），如果有其他兄弟应用系统在它自己的服务器中需要改变在它某件事情时需要订单业务数据参与处理，那它从它的应用中调用我好了（业务逻辑变化，需求增加）。呵呵，你说这是不是从技术方面提供了一个很好的适应需求变化的手段呢，你不要告诉我你说的那些EJB能做的我用其他的都能做哦，那当然了，但i服了you，如果你也去写另外一套的 ejb的话，自己学rmi啊，自己来处理事务啊等等，天啊。
所以需求变化是要业务组件来适应的，而不同的业务组件有着不同的适应能力，就是所谓系统的伸缩能力，如果你用一般的java
class做为业务组件的话，你适着想上面问题的解决，你头会大的，明白吗？呵呵，好了，我觉得我们老是离题好象，架构提供的是什么，是适应适应你的需求变化的组件。需求变化需要业务组件的变化来适应，架构只是埔助业务组件完成业务组件所需要的服务。
Re: 项目规模的界定!
发表时间: Dec 3, 2004 9:57 AM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
to neksai
我觉得你的说法有些偏执一个"完美"的方案或设计.ejb固然好,但是你能保证他不被淘汰嘛(我只是假设...)
你所有的问题都从技术的角度去看,是无法看清全局的...
Re: 项目规模的界定!
发表时间: Dec 3, 2004 10:46 AM
回复
发表人:
nekesai 发表文章: 25 / 注册时间: 2004-10
我想你理解错了，我何来偏执，从那些信息得出？我也没有表达所有问题技术角度解决就可以了，我是说就技术的角度，因为大家在这里说的更多的是到底是 with Ejb还是without eej,是技术问题引申出来的到底需求难于界定的时候采用何种技术，是讨论从技术方面解决需求变化的问题，那么我也推荐就主要而言采用ejb技术是比较好的，我也举了例子来说明从技术角度来提供一种手段。不否认，管理上的管理和控制来的更有效，你可以看其他帖上关于我对需求变化从管理方向的一些建议和理解。
在说我从来就不是ejb的传播者，也不是其他方案的支持者，我就是要按自己对事务本质的理解来选择自己认为合理的技术方案，听清楚了是技术方案，这里我说的技术，我也说了技术只是一个风险中的小部分，不要看了就瞎说我什么从技术来看全局，技术的方案是等你看完全局后才做决定的，当然要权衡，如果就什么都不考虑，为了满足伸缩性，当然是EJB了，我是这么说的。
置于ejb要淘汰的话，我只能告诉你那一定有另外一种能满足现在EJB所有的好处以上的EJB出现（这句话好好好想想，为什么这么说），而不是因为现在有什么hibernate或者有spring框架，这些都不能作为ejb要淘汰的依据，因为他们没有EJBde 优点。当然如果某个人定义出了更好的一种ejb规范，那也是现在的ejb淘汰之时。君不见的ejb1.X的时候,you有新的一种ejb2.0来替代，而不是什么OJB，千万不要认为ejb1.X和ejb2.0不都是EJB吗，它们只是名字有点像和定义他们的都是同一个父亲SUN,但他们是有很多不一样的，那马上要到来的EJB3.0要出来了，当然它跟EJB2.0又有很多不一样，说到此，不管是不是把EJB2.0和EJB3.0的名字改不改为 nekesai还是Kidwish，这都不是本质的东西，本质的东西就是他们都跟EJB1.0一样支持分布式计算，事务容器自管理，安全和服务容器能提供等好处，不管谁代替谁都要有这些东西。
呵呵，所以我觉得那些问“你能保证ejb不被淘汰吗？“的问题，是一个很傻的问题，不值的问，为什么，因为我基本就不管它是不是EJB，我只管它有没有ejb的好处就行，哪怕它来个变脸说我EJB3.0要变成NEKESAI1.0了哦，你用不用，用的话我告诉你ejb已经淘汰了哦，哈哈，这是傻瓜，NEKESAI1.0不是一样做做着ejb那些勾当，换汤不换药。但如果你把药都换了就如 hibernate，是不能代替EJB的。为什么，自己想想，想些本质的东西，不要瞎掰。
Re: 项目规模的界定!
发表时间: Dec 3, 2004 12:09 PM
回复
发表人:
Kidwish 发表文章: 14 / 注册时间: 2003-08
to nekasai
我觉得在这里争论ejb或without ejb没有多少意义，每个人站的立场不一样...
ejb是有很多pros，但是也是有很多cons的。究竟应该怎么样，应该由决定采用他的人来决定。回到最初的80/20，就是那么回事。他根本不用什么鼓吹。你“觉得”好用，够用，OK！就是他了！
本文地址：http://com.8s8s.com/it/it12945.htm