这个人试图指出我们实践中的80%的系统是不需要XXX，进行这样的断言，已经超出用极端两个字，我提倡技术上可以用极端，例如，你可以说，Spring技术设计完美无缺，我无可非议，因为技术人员谈技术，极端一些是正常。
但是，技术人员试图对技术以外的需求指手画脚，不论他是谁，我是极端反感，并一定骂他狗血碰头，不管他是什么世界名家和妄图成名之类的鸡犬之徒。
我在csdn上也发了相同的帖子,有兴趣的可以去捧捧场!先谢了!
http://community.csdn.net/Expert/topic/3603/3603919.xml?temp=5.256289E-02
如果需求能够断言，那么银弹就诞生了，问题是：需求是永远变化的，你很难对你的客户需求进行断言，你唯一要做的就是:做好适应变化的准备。
以某个小企业的进销存系统为例子，今天给你做的可能是一个小系统，不需要什么分布式等等，但是企业出口获利，中国企业的规模膨胀速度是世界有目共睹的，当你给他做了一个不具备伸缩性的系统后，这个系统就可能成为阻碍他发展的绊脚石，你要适应他发展，就要更改架构，重写编写？
所幸，Spring提供了依赖EJB的可伸缩性，这是他的明智之处，但是如果你提出without EJB，那么你的存在价值在哪里，仅仅靠一句断言：80%不需要分布式EJB？
"中小型的项目使用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世界”就是表明了程序员的这种困惑，可惜这样实际的问题遭受了程序员杂志的封杀，我也再不会给程序员杂志写稿了。
欢迎每个人发表观点，对事不对人是Jdon论坛争论的宗旨，因此，不管什么人都可以理直气壮发表观点，我以前说过“太阳死了”意思是这里没有什么所谓技术权威，而是争论，有理性的真正的争论，初次发言者也无需战战兢兢，版砖随时会砸来，但这不能阻碍我发言的自由，我要自信。
这里针对Java和.Ｎet的就是最好的例子，为什么有人总是再说谁是谁非呢？因为他们陷入了技术的旋涡！没有看清一些事实罢了！或者说他们站在一个高度去＂盲目＂地指挥...
好了，说到这，又些人就会问我了，有多少的系统的业务像你们客户全球性的，呵呵，我只能说你不懂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是没有关系的。
软件技术的风险占的比率是整个风险的很小一部分。
在这里我们更关心的是如何让才能让项目“活”着，也是我们在考虑项目规模如何界定的问题，因为它的“活”，所以这个需求导致的项目scope是模糊的，并且一直模糊下去，否则就没有“活”着。但我们就从技术角度来怎么保证这个项目的“活”导致的膨胀呢，那就是伸缩性。
不要说在这里我还需要去解释什么是伸缩性吧，伸缩性不只是性能哦，在技术性上保证了伸缩性那就很容易适应业务的变化，甚至其他网络和硬件上的物理变化。
我认为确切地说应该是架构的可伸缩性。伸缩性何来？大部分人可能考虑的是系统功能性方面的架构因素，但是这是不够的，往往忽略了非功能性的考虑，诸如质量，维护，技能，人员等。所以好的架构不是鼓吹出来的：什么轻量级的容器，EJB负担之类。是应该来自对问题域的理解，寻求方案而来。
技术是要关注的，我始终觉得一个好的设计人员，应该了解各类技术，但是不是偏执一个“完美”的设计！
我也在寻找，但是要知道这是多么困难。就如抽象一样...
但是，我已经发现有些行之有效的方法论的东西。我的观点是取长补短，灵活驾御。
好的架构思想很多，架构模式方面的书籍也很多。要寻求好的架构，我认为来源就在自己手里--需求。
我的想法是保持增长，但是要注意大粒度。
ＰＳ：话题有些远了....