项目规模的界定!

我们知道，需求是软件之母，只有人类的实践需求，才会有软件，才促进软件发展，如果有个人试图对人类的需求进行指手画脚，只可能有两种人：1.别有用心的人；2.傻子。

这个人试图指出我们实践中的80%的系统是不需要XXX，进行这样的断言，已经超出用极端两个字，我提倡技术上可以用极端，例如，你可以说，Spring技术设计完美无缺，我无可非议，因为技术人员谈技术，极端一些是正常。

但是，技术人员试图对技术以外的需求指手画脚，不论他是谁，我是极端反感，并一定骂他狗血碰头，不管他是什么世界名家和妄图成名之类的鸡犬之徒。

首先谢谢banq的回复,不过说实在的,看了你的回帖我还以为我说错了什么话,还好话都是别人说的,我转一下而已.这个论坛我来了不少,也在其中的争辩中学到了不少东西.但有一个感觉是这里的人好像火气比较浓(可能技术上有所专长的人都这样吧),所以也战战兢兢不敢发帖子呀,呵呵.帖子既然发出来了,我还是想听一下大家的意见.再把需求描述一下吧:中小型的项目使用web服务器就已足够,可是大规模的项目使用ejb或者使用web service,或直接调用rmi能使项目具有更大的弹性,但由此也带来很多开发和性能上的代价.那么我们进行项目开发时,项目规模的这个度怎么来界定?
我在csdn上也发了相同的帖子,有兴趣的可以去捧捧场!先谢了!
http://community.csdn.net/Expert/topic/3603/3603919.xml?temp=5.256289E-02

干技术的似乎总觉得“流行就是好的”，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那一部分，规则不是也有例外吗。罗嗦这么多，总之前提是不能脱离项目本身的需求，另外还要考虑软件的实现和维护成本，是从工程的角度考虑，而不只是从技术层面上考虑。

谢谢ljshan 的关注,我也明白其实需求是第一位的,项目能做好,用户满意是第一位的,一个项目的开发选用什么工具要考虑很多因素,比如硬件,资金,开发人员的技术水平,我在这讨论的其实是一个很简单的问题,可能我的表述还不是很确切.简单的说,算是做个调查,也算是做个交流,平常大家开发都选用什么框架,基于这样的框架能满足多少人同时访问,速度如何?

shipatrioc 误会了我的意思，我是炮鸿那个without EJB的作者，他作为一个专业人士，竟然对另外一个领域：需求，进行断言，更有甚者，他后面所有的逻辑都是依赖这个站不住脚跟的观点。

如果需求能够断言，那么银弹就诞生了，问题是：需求是永远变化的，你很难对你的客户需求进行断言，你唯一要做的就是:做好适应变化的准备。

以某个小企业的进销存系统为例子，今天给你做的可能是一个小系统，不需要什么分布式等等，但是企业出口获利，中国企业的规模膨胀速度是世界有目共睹的，当你给他做了一个不具备伸缩性的系统后，这个系统就可能成为阻碍他发展的绊脚石，你要适应他发展，就要更改架构，重写编写？

所幸，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的就是最好的例子，为什么有人总是再说谁是谁非呢？因为他们陷入了技术的旋涡！没有看清一些事实罢了！或者说他们站在一个高度去＂盲目＂地指挥...

Kidwish 的让项目“活”着观点也是我要表达的意思，我认为强调可伸缩性是让项目“活”着的一个好建议。

哈哈，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是没有关系的。
软件技术的风险占的比率是整个风险的很小一部分。

Kidwish 提出的问题很好，只是我很希望他能提出解决问题的方法。

在这里我们更关心的是如何让才能让项目“活”着，也是我们在考虑项目规模如何界定的问题，因为它的“活”，所以这个需求导致的项目scope是模糊的，并且一直模糊下去，否则就没有“活”着。但我们就从技术角度来怎么保证这个项目的“活”导致的膨胀呢，那就是伸缩性。
不要说在这里我还需要去解释什么是伸缩性吧，伸缩性不只是性能哦，在技术性上保证了伸缩性那就很容易适应业务的变化，甚至其他网络和硬件上的物理变化。

“我认为强调可伸缩性是让项目“活”着的一个好建议。”

我认为确切地说应该是架构的可伸缩性。伸缩性何来？大部分人可能考虑的是系统功能性方面的架构因素，但是这是不够的，往往忽略了非功能性的考虑，诸如质量，维护，技能，人员等。所以好的架构不是鼓吹出来的：什么轻量级的容器，EJB负担之类。是应该来自对问题域的理解，寻求方案而来。

技术是要关注的，我始终觉得一个好的设计人员，应该了解各类技术，但是不是偏执一个“完美”的设计！

“Kidwish 提出的问题很好，只是我很希望他能提出解决问题的方法。”

我也在寻找，但是要知道这是多么困难。就如抽象一样...

但是，我已经发现有些行之有效的方法论的东西。我的观点是取长补短，灵活驾御。

好的架构思想很多，架构模式方面的书籍也很多。要寻求好的架构，我认为来源就在自己手里--需求。

还有一点我觉得要注意，软件项目中的＂阴影＂，就是不断膨胀的系统和功能！－－＂阴影扩散＂

我的想法是保持增长，但是要注意大粒度。

ＰＳ：话题有些远了....