比较话题: 轻量级与重量级比较
收到一封关于 pojo in action 图书的信。
------------------ editor said
我是营销编辑。为了更好的销售图书《POJOs IN ACTION》，我想做一个EJB VS POJOS专题，您一看专题就能明白，我想做一个轻量级与重量级比较。形式是：引出一个话题，吸引读者。目的是：
读者买这本书。但是我遇到了一个问题：我不太清楚如何引出一个比较的话题，让读者
购买这本书。我不好把握这个尺寸，我想请您指导
------------------ co translater said
hi, buaawhl
能否由你联络杜编辑，帮他策划一下？谢过！
------------------ buaawhl said
如果要比较的话，主要从几个层次来比较。
包括持久层，服务层，web层。
另外还有一个问题，和什么比较。
EJB分为两种，一种是 EJB 2.x, 一种是 EJB 3.x。
如果是和 EJB 2.x 比较，那么比较简单，因为 EJB 2.x 是重量级的框架标准。
Spring 作者写了一本<<without EJB>>，可以说，是专门比较 pojo 和 EJB 2.x。
不过，EJB 2.x 已经被 Spring 作者的<<without EJB>>那本书打垮了。近两三年EJB 一般都是指 EJB 3.0。
EJB 3.0 基本上已经是 POJO 了。EJB 3.0 主要分为两个部分，持久层( JPA) 和 服务层(session bean)。持久层部分已经是 POJO。
服务层(session bean) 部分需要用到 JNDI，还不是完全的 Pojo。
所以如果要pojo 和 EJB 3.0 比较，那么可比较的部分，主要就在 session bean JNDI部分。
JNDI是java 命名服务，是一种传统的工厂模式(factory pattern)，正好和pojo 的 IoC 模式相对相反。
所以，我个人的想法是这样。专题可以这样策划。
首先引出大的范畴比较。
lightweight (轻量级) vs heavyweight(重量级)
lightweight = POJO + IoC
(需要注意的是，POJO 和 IoC 是相辅相成的，如果要实现 pojo，通常来说，少不了IoC 模式的支持)
heavyweight = 传统框架 + 传统工厂模式
传统框架包括EJB 2.x, EJB 3.0 session bean, 等，还包括其他的需要非Pojo的框架。
从严格意义上来说，目前的所有web框架，都是非Pojo的传统框架，都是重量级框架，都没有达到pojo的标准。这就是说，pojo的春风并没有吹到 web 层，只是吹到了服务层往下。
传统工厂模式，包括JNDI。
pojo in action 里面着重描述了如何把 JNDI 包装成可以达到 pojo效果的 IoC模式。
这样可以分出两个小范畴的比较话题。
POJO vs NON POJO
IoC vs Factory
POJO vs NON POJO 的优点在于，POJO框架具有最强的兼容性和适用性。不需要改动代码，就可以包容遗留代码。NON POJO框架就需要改动以前的Java类。
IoC vs Factory 的优点在于，IoC有一定的开放性，允许程序员自由包装POJO，然后注入到其他的POJO，在这个包装和注入的过程中，就可以做很多小动作。夹塞，夹代什么的。在IoC框架中，AOP用起来很容易。 Factory就没有这么方便了，Factory是封闭式的，很难在Factory工作的过程中夹带私活。
然后，在可测试、可扩展方面进行一些比较，应该就差不多了。比如，POJO + IoC 的可测试性、可扩展性，要远远好于 NON POJO + Factory。
其他的，还有什么呢？
----------------------------
脱离网络太久，有些落伍，最新的技术进展跟不上了。
想听听大家的意见。thanks.
1 楼 sptzone 2007-10-31 我觉得重量级和轻量级的不同更多的在于重量级会定义许多的接口让你去实现（虽然这一部分是为了使开发商更好地生产相应标准的产品），轻量级就少了许多这些注入，象Spring这样吧。
JNDI不过是通过特定的协议返回远端资源，得到之后反序列化，取出对象，这一点是应该和重量级没有太大的关系。 2 楼 rehte 2007-10-31 sptzone 写道我觉得重量级和轻量级的不同更多的在于重量级会定义许多的接口让你去实现（虽然这一部分是为了使开发商更好地生产相应标准的产品），轻量级就少了许多这些注入，象Spring这样吧。
JNDI不过是通过特定的协议返回远端资源，得到之后反序列化，取出对象，这一点是应该和重量级没有太大的关系。
赞同。重量级其实和使用不使用JNDI是没有任何关系。JNDI其实是一种资源访问机制，而不是业务对象的生命管理机制。重量级和轻量级最本质的区别在于框架的灵活性。传统的以接口为驱动的模式，使得容器本身比较容易实现，容器在实例化化业务对象后，传给业务对象上下文，而业务对象本身要通过JNDI手段来定位或者pull出其他资源或者业务对象，这同IoC(Inversion of Control，反向控制，DI依赖注入，有容器提供资源或者其他业务对象并push给当前对象）的方式正好相反。由于这种业务对象需要实现很多预先定义的框架接口，使其相对于所谓POJO(Plain Old Java Object)这种不受约束显得非常笨重，因而才出现了所谓重量级的名称。
3 楼 timerri 2007-11-01 所谓重，就是架构与对象耦合度高~
对象很难脱离架构运行。
4 楼 w_y_g 2007-11-27 重量级的开发倒并不是指EJB或者是JNDI，很大意义上，重量级的开发都是需要依赖一个非常庞大的容器系统进行开发，在EJB的开发中，我们所有开发的内容基本都需要放置在一个容器系统中进行运行，这些容器因为基本针对大型企业应用，所以体积庞大，占用资源过多，在开发的过程中效率很低，因为使用大型容器作为开发环境的话，我们很大一部分时间都用在了Deploy、Run，这样的过程上，有时候改动一个小小的部分，需要等等很长的时间才能看到结果，如果做单元测试也比较麻烦，虽然现在有很多针对容器的单元测试框架，但是还是没有很好的解决Deploy的等待问题，所以在开发者这里，EJB逐渐失去了很多的吸引力，因为感觉实在是太笨重了。
轻量级框架的优势很大程度上是因为加速了开发的速度，我们不用部署一个很庞大的容器系统就可以实现以前需要容器才能实现的功能，我们可以使用Spring代替EJB中的Stateless Session Bean，可以使用Hibernate代替EJB中的Entity Bean，而且我们可以直接写一个Application运行已经完成的系统，马上可以看到结果，做单元测试非常的简介，不需要做太多的工作就可以构建系统，这些特性对于开发人员来说非常的有吸引力。
关于轻量级和重量级之间的论战已经由来已久了，也最终没有出现一个很好的结果，重量级框架在大规模运行的时候会表现出非常优异的性能，劣势主要是开发效率较低，轻量级框架正好相反，开发的时候非常迅速，但是在大规模运行的时候，性能比重量级框架还是有差异。
但是随着最近一些框架标准的成熟，可以有新的选择，因为不管是轻量级还是重量级框架，基本解决的是两个问题，一个是“事务控制”，一个是“持久化控制”，在JPA标准发布以后，我们看到一个很好的解决方式，“持久化”的开发可以和任何框架没有关系，直接使用JPA的标准注解即可，所以开发“持久化”部分的时候可以使用JPA进行注解，开发时期用Hibernate作为JPA的实现进行开发测试，需要上线运行的时候就可以直接部署到EJB 的EntityBean上，在EJB3.0之后，已经很好进行移植部署。关于“事务控制”，现在所有的实现方式都比较简单，针对方法进行注解事务类型即可，开发的时候可以用一个转换器将这些注解转化为Spring的 映射，快速的进行开发，在上线运行的时候，直接使用EJB的Session Bean进行部署就可以解决，这些方式实现起来并不困难，可以很好解决“重量级”和“轻量级”之间的矛盾。
5 楼 抛出异常的爱 2007-11-27 如果开发简单，出错少，我不反对重量的东西。
但是重量的东西可以卖很贵的价格。。。。是我非常憎恨的 6 楼 hyhongyong 2007-11-27 抛出异常的爱 写道如果开发简单，出错少，我不反对重量的东西。
但是重量的东西可以卖很贵的价格。。。。是我非常憎恨的重量的东西自然卖的很贵，要不人家拿什么让你出钱呢。