收到一封关于 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.
------------------ 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.