欢迎进入Java社区论坛，与200万技术人员互动交流 >>进入
灵活性/定制性/透明性
当然这个答案有时我们自己也可能很难给出，那么我们还需要从其他角度来考量EJB和非EJB之选，例如笔者曾经经历一个大型实时娱乐平台社区系统，从规模上说肯定是大型系统，设计目标10万人在线，从这个角度非选用EJB不可!
但是，EJB因为还有事务机制，虽然应用程序可以选择失效EJB事务，但是EJB容器设计因为考虑了事务，所以在其内核上总是会显得臃肿，是一种累赘，这也是一种重量表示，不需要的东西存在肯定会影响效率，那么难道我不能根据我的需求，对EJB整体包括EJB容器进行可配置式的切割?也就是说，我上面这个案例只需要EJB的分布式计算功能，其他的功能我都拆除，只剩余我需要的功能能运行就可以了，轻装上阵。
可惜，这种任意切割，应需而定的目标在EJB3标准还没有被重视，所幸的是，Ioc/AOP技术为这种目标实现提供了实现可能，但是，只有Ioc/AOP还是不够，特别是看Ioc的范围，如果你只把应用系统组件纳入Ioc管理时，自由解耦只属于应用系统，我上面案例的目标还是无法达到，当你把框架本身组件也纳入Ioc管理时，任意切割，应需而定的目标才真正实现。
Spring和EJB3属于“只把应用系统组件纳入Ioc管理”，这从JBoss 4.0版本可以看出;那什么框架会把框架本身组件也纳入Ioc管理呢?Apache的Hivemind和笔者开发的Jdon框架。
什么样的组件可以被纳入Ioc管理呢?POJO组件，POJO这个概念其实当初是针对EJB缺点而推出，EJB要求应用系统的组件必须继承或依赖EJB容器，这样使得调试变的不方便，但是后来，POJO的概念已经不只最初这些概念，POJO代表那种与周围完全脱离关系、自由自在的Object了，如果应用系统的Model或者Service都是POJO，意味着你的应用系统不依赖任何其他系统，解耦性灵活性高。
POJO是因为EJB而提出的，当EJB自己倾向POJO时，大家都在宣称自己是POJO时，POJO概念就没有立足点了，这也是Java领域哭笑不得的现象，但是我个人更倾向把非EJB的JavaBeans组件通称为POJO。
Hivemind的Ioc依赖注射部分功能和Jdon框架非常类似，当上百个POJO组件配置时，完全不必指定它们之间的依赖关系;你可以将自己应用程序的组件注册到Registry中，这样Hivemind将帮助你启动这些组件，正如你在Jdon框架中将你的组件写入mycontainer.xml中，Jdon框架也将自动启动你这些组件，并解决它们之间的互相调用，包括和框架本身组件互动。
HiveMind和Jdon框架定义的POJO Service有如下特点：
不象EJB那样缺乏本地透明化(location transparency)概念，这些POJO Service总是能定位到同样一个JVM;也不象基于XML的Web服务web services那样没有语言透明(language transparency)概念，这些POJO Service总是可以被一组Java接口来概括替代(通过调用Java interface来替代调用这些具体Service);当然，更不会类似JMX或Jini，不能进行service的热装载( hot-loading)。
注意：当Ioc/AOP提供高度灵活的同时，已经有初学者开始抱怨Spring的过分灵活，那么比Spring在组件上更灵活的Jdon框架只能算是一种追求极端，它不一定构成你进行架构选择的主要依据!
上面这些讨论只是表明在灵活性(解耦性/透明性)这条需求道路上深究下去的选择，你自己的应用系统需求会产生各种不同的要求，有些要求甚至是极致的，这种偏向程度就成为你架构选择的目标，如果你的这种极致要求在目前Java世界里还没有可选框架时，那么你就要动手自己做了，这也说明什么时候你开始自己做框架(如Jdon框架)，虽然在大多数情况下我们是不必要自己发明轮子的。
快速构建性
前面是从灵活性和定制性这个角度讨论架构选择目标，但是在一般情况下，我们还是从上手难易、开发效率这个角度来进行架构选择，从这个角度来说，就是需要我们将选用的框架尽可能的多帮助我们实现一些功能，但这又是和使用难易是矛盾的，因此有个取舍问题，取舍有个准则：这个框架尽量能提供越多功能;尽量需要我们少写代码，甚至不写代码(使用XML配置)，少动脑筋。
关于XML配置这里也涉及难易问题，XML配置语法不能太复杂，有太多小开关Switch也增加学习成本。
从这个角度看，EJB无论是EJB2或EJB3提供的功能是最齐全的，但是XML配置开关太多 ，Spring属于中等，组件XML配置不算简单，但是因为有不少Struts+Spring+Hibernate之类现成开源代码可供参考，因此学习起来难度也不大，Spring越来越象一个J2EE API(注意，JDK是J2SE API) ，Spring除不能提供分布式计算外，也因为过分灵活降低了一些开发效率，例如它的组件依赖关系一般需要逐步指定，auotwiring功能还没有深入骨髓成为核心功能。Ioc容器的革命性优点。
Spring除了提供组件层功能以外，还有表现层支持Spring MVC;也有持久层实现的JDBC模板，这样，整个J2EE/Java EE系统各个层次Spring都提供了缺省实现，在这方面无疑提高了开发效率，但是Spring提供丰富API目的好像不是为了快速开发，而是为了建立一个完整的功能齐全的API功能库。正如它网页上开头文字所述：As the leading full-stack Java/J2EE application framework，注意full-stack(完整齐全)是它突出的名词。
那么，还有另外一个空白，就是以开发效率为主要考虑，这类框架除了必须考虑足够灵活性和丰富功能以外，宗旨是为了在一般缺省情况下快速完成一个J2EE/Java EE系统，这非常类似MDA工具了，但是一个完全丧失灵活性和定制性的MDA工具也不是我们欢迎的。
Jdon框架的发展目标是为了填补这个空白，相信也会越来越多框架向这个目标迈进，当然不可否认，Spring也可能调转枪头走入这个领域，EJB2/EJB3正依靠JBuilder等这样商业化开发工具向这个领域靠拢，这个发展方向实际是4GL RAD Tools。
很多人在快速构建方面也很早进行了探索，涌现出各种工具：如何构建一个快速业务构件平台? 但是如何把快速构建和构件(组件)灵活性有机结合在一起?它是考验一个业务构件(业务组件)平台好坏的准则。有些构件平台虽然开发迅速，但是对于特殊情况，可供程序员定制透明操作部分不多，很死，典型的是两层结构以前的Delphi，开发很快速，但是无法象J2EE这样深入到系统各个层次进行定制/维护/拓展!
业务组件框架对比
EJB2/EJB3 Spring Framework 1.x Jdon Framework 1.x
灵活性
(松耦合) EJB3比EJB2更具灵活性，EJB3支持应用系统POJO 支持应用系统POJO，框架基础功能不能替换 支持应用系统POJO，框架本身可分离配置，定制性更强
功能完整性 全面，支持异步JMS 分布式事务 较为全面。有自己的表现层和持久层模板,可支持异步 基本完整，表现层借助Struts实现。有自己简单的持久层模板
领域范围支持业务逻辑Session 不支持，需要开发者额外基于ThreadLocal编制代码，耗费精力和时间。 支持业务逻辑Session
Ioc/AOP支持 EJB3支持Ioc, JBoss等EJB3服务器支持AOP;基于业务组件的较粗粒度 基于JavaBeans类的细粒度;一般小型应用过于灵活带来复杂。 基于业务组件的较粗粒度
Ioc是否支持autowiring EJB3支持 缺省不支持，可设置支持 缺省支持
单台性能 一般，批量查询等大数据量业务处理须小心，存在本地不透明缺陷。 一般，框架本身组件无性能提升极致，应用程序可配置cache/Pool 好，框架本身组件使用缓存提升性能，应用程序可配置cache/Pool，批量查询专门优化，适合实时性并发性要求较高应用
可伸缩性可支持多台服务器分布式计算。不支持，可依靠EJB实现
开发效率 学习曲线长,导致熟练掌握难。借助商业开发工具可加快熟练者的开发速度。 较为复杂，可挑选只适合自己的功能实现。当组件很多时，需要照顾这些组件之间调用关系。 简单快速，表现层编码很少。当组件个数很多时，无需照顾它们之间的调用关系
系统规模 EJB2适合大型系统;EJB3适合中大型系统 适合中小型系统 适合小中型系统，建立一个简单的网站系统等，和EJB无缝结合，可借助EJB支持中大型系统
重量级别重量，正在减肥 轻量偏重，有可能继续增肥 最轻量，恪守简单快速原则
[1][2][3]
没有口水与汗水，就没有成功的泪水。
