|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
robbin 写道 EJB是怎么来的吗？它本来就是从TP Monitor和分布式对象管理器发展而来。所以EJB的真正价值本来就是Transaction 和 Distribution。我从来不知道有人会误解EJB不是Transaction based的。所以这一炮等于自己虚构出来一个靶子，然后对它猛烈的开火。 robbin你可以这样讲，可是太多文章只提ejb的distribution，不提transaction，我的确发现很多人根本不知道ejb是transaction-oriented的，我有虚设靶子吗？ robbin 写道 任何技术的使用都是有一定的前提的。就好像批评Hibernate不适合OLAP，批评汇编语言不适合OO一样，脱离了应用的前提，讨论就失去了意义。如果不限定scope，比较Spring和EJB也是没有任何意义的。 我觉得你与其拿着规范泛泛而谈，还不如像你自己所说，限定一个scope，然后再进行比较。例如在XX行业，什么比较好，在XX环境下，什么比较好，诸如此类。 对，但是作为一种组件结构，技术是有可比较性的。 robbin 写道 任何框架都是有侵入性的，完全没有侵入性的框架是不存在的。你首先设定一个我们都不认可的前提条件，然后说如果我们不接受这个前提，就不要浪费时间往下看了。这还是等于自己虚构出来一个没有人认可的靶子，然后开火。 我根本就没有比较ejb和spring的侵入性，我比较的组件约定。这个该是component architecture规定的，当然可能对ca有不同的理解。那么是robbin自己虚构出来一个靶子吧。 robbin 写道 你对复用的理解是不对的。组件的复用有一个前提，是在他的容器内的复用。也就是说你应该比较的是在Spring里面编写的组件，它在Spring环境中的复用程度，和EJB环境里面写的EJB组件他的复用程度。而不是你所说的组件写好以后，我们把容器完全抛开来谈复用。所以你仍然在设定一个虚拟的靶子开火。
好，robbin认为复用该在容器里，我也认为，可就有人说不对，还比较过pico一直到spring，ejb移植到avalon.我有虚设靶子吗？ 引用 嘿嘿，组件里面完全没有技术代码是不可能的，我们只能做到技术代码比例尽量的低，事实上，反倒是EJB里面混有的技术代码比例远远高于Spring组件，这一点，如果你编写过EJB，不会不清楚。
我写过，简单应用可以没有，复杂应用会有，但是隐藏在ejb api里了。比如jndi lookup。jndi是j2se的标准api，复用是不是比spring api好呢？ 引用 我上面已经说了，复用不能脱离容器来谈。你现在树立的靶子是脱离容器谈复用。
对，我没准对robbin你，我也认为复用不能脱离容器。至于离开复用，我认为需要mock container context. 引用 我还是强调复用不能脱离容器来谈，compomentA他永远只在Spring这个SystemA中，而不会搬到SystemB去。所以你下面那些话又是自己树立了别人都不认可的一个靶子，然后开火开的十分起劲。
那么很多人鼓吹pojo复用指的什么呢？还不是在另外一个系统里来用，那么两个系统context有差异，就要复用context，同样，robbin你的看法和我一样，我设的靶子不是你，但是也不是谁也不认可的靶子。 引用 EJB需要一个部署的角色，但不是你理解的那种角色。他并不是如你所说的来粘合技术和业务，编写ejb-jar.xml的，这些工作是程序员自己的事情。部署者他的真正角色是应用服务器管理员，他要做的事情是监视应用服务器的性能，对应用服务器进行性能条件。我建议你多接触一些EJB项目，特别是分别做一下这些角色，我还是感觉你缺乏这种经验。
对不起robbin，这里我写错了，技术和业务既然分开了，就一定要再合上，那么谁来合？谁来粘合技术和业务？assembler，不是deployer。 引用 另外就是文章大多数观点都是先树立一个别人都反对的论点，然后自己批的很高兴，所以没有什么他多可以争论的话题。
no robbin，你所谓别人都反对的观点，并不是所有人都反对。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
robbin
引用 特别是像Spring，Hibernate，EJB这种框架，你应用了它，就等于接受了他一整套设计理念，要想无痛的切换到其他框架上面，是不可能的。
我还是强调我的业务组件的复用，特别是无状态的业务组件的复用。一个业务组件是一个纯粹的不依赖与任何容器类的话，自然也就不需要特定的容器实现。当然底层的Hibernate不在我们讨论之列。 至于说到项目采用Spring而接受它的一整套设计理念，我想项目里采用Spring来作整个系统运行的核心容器，还是不明智的。Spring没有提供容器管理的一些特点，相反，采用Spring作为底层支撑核心容器的运行，倒是合适的思路。这里大家把Spring作为容器看待，我也持反对意见！spring提供对象实例化以及IoC，AOP的实现，倒是作实现容器的底层框架支持的不二选择！呵呵 我的容器的概念是JSP container（Tomcat，Resin），EJB。这些提供一系列的对各个组件的生命周期管理规范的container，才是我讨论的container。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
to robbin
其实我们对ejb的认识没有分歧，我也使一再强调ejb的transaction-oriented和component复用仅在指定的容器内，不过因为对ejb有太多的误解，我才写这样一篇文章，同样我自己也觉得没意思，因为从某种意义上讲，都是再明白不过的废话了。 我没有说ejb一定胜过spring，我强调的庄表伟兄已经替我说了，spring的简洁如何配合一个统一的开发语义，那么才是我们真正需要的，ejb向简洁发展，spring向完整发展，就是这样。 这里我要说的不是ejb优于spring，而是比较他的component architecture，还有一些所谓的复用。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
>>jndi是j2se的标准api，复用是不是比spring api好呢
这句话足以代表楼主的整个观点：有标准的就一定比没标准的复用性好。所以整个讨论就不再是复用性的问题，因为楼主心里想的就是标准不标准的问题。JNDI的复用性就一定比较好吗？JNDI是什么？说白了就是一个Service Locator，一个工厂。那么究竟是工厂的复用性好呢，还是Dependency Injection的复用性好？或者说，究竟是JNDI的复用性好呢，还是一个setter或者constructor的复用性好？或者再简单点说，下面两段代码，哪个复用性好？
private MyBean _bean = JNDILocator.getBean("myBean");;
public void doSomething(); {
_bean.doSomething();;
private MyBean _bean;
public void setMyBean(MyBean bean); {
_bean = bean;
}
public void doSomething(); {
_bean.doSomething();;
}
|
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 >>jndi是j2se的标准api，复用是不是比spring api好呢
这句话足以代表楼主的整个观点：有标准的就一定比没标准的复用性好。所以整个讨论就不再是复用性的问题，因为楼主心里想的就是标准不标准的问题。JNDI的复用性就一定比较好吗？JNDI是什么？说白了就是一个Service Locator，一个工厂。那么究竟是工厂的复用性好呢，还是Dependency Injection的复用性好？或者说，究竟是JNDI的复用性好呢，还是一个setter或者constructor的复用性好？或者再简单点说，下面两段代码，哪个复用性好？
private MyBean _bean = JNDILocator.getBean("myBean");;
public void doSomething(); {
_bean.doSomething();;
private MyBean _bean;
public void setMyBean(MyBean bean); {
_bean = bean;
}
public void doSomething(); {
_bean.doSomething();;
}
ApplcationContext.get("xxxx")； 和 context.lookup("xxx")有多大区别？ 注射是实现细节，jndi内部一样可以注射 起码，包依赖上讲，jndi好一些，j2se自带。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 ApplcationContext.get("xxxx")； 和 context.lookup("xxx")有多大区别？ 注射是实现细节，jndi内部一样可以注射 起码，包依赖上讲，jndi好一些，j2se自带。 终于搞明白了。原来您根本就不知道Spring是怎么个用法呢。不妨先去问问ajoo，我们有没有任何时候需要ApplicationContext.get("xxxx")的？这就是ajoo同志一直说的，冤魂不散的对IoC容器的误用。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 比如说事务，那么语义有什么？ejb给了一个集合：NotSupported,Supports,Required,RequiredNew,Mandatory,Never,Bean Managed 其实这是ejb事务争用的模型，也是ejb事务争用的语义(我想我偏爱语义这个词大概是受林星的影响，林你在看吗：）)，和实现机制没关系。这就是组件的技术语义。 这个，spring也有啊。看起来好像也不缺，也有一大摞。只不过和ejb的有那么一点点不同。 举个ejb有spring没有的例子看看。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
To raimundox
基于我的EJB实践，有两个关于EJB的观点我不同意。 1、EJB分离技术代码和业务代码，技术代码比Spring少 EJB的Bean里面那些个Context方法干啥的？Home接口有是干啥的？那些create和close方法又是干啥的？EJB在事实上强制你填充他设定好的技术代码框架，EJB企图分离技术代码和业务代码，但是做的非常不成功。Spring没有限定一个工厂框架来强制你把lookup分离出来，但是一个风格良好的程序员都会这样做的。 2、不管集成，还是部署也好，这种角色的设定不是为了分离技术和业务 事实上之所以设定，就是因为EJB太复杂了，而不同App Server的EJB部署起来又非常不同，因此必须要有这样一个人来负责协调各个EJB之间的冲突问题。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 ApplcationContext.get("xxxx")； 和 context.lookup("xxx")有多大区别？ 注射是实现细节，jndi内部一样可以注射 起码，包依赖上讲，jndi好一些，j2se自带。 终于搞明白了。原来您根本就不知道Spring是怎么个用法呢。不妨先去问问ajoo，我们有没有任何时候需要ApplicationContext.get("xxxx")的？这就是ajoo同志一直说的，冤魂不散的对IoC容器的误用。 赫赫，我是说明spring的container中applicationContext其实一种naming service而已，和Jndi地位一样，跟怎么用有关系吗？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
庄表伟 写道 to:potian,gigix
“可用”和“可复用”是两个概念。 POJO在哪里都可以再次使用，一个简单的对象而已。 但是要能够复用，不是能够把这POJO new出来就算是用起来了。 你认为我不理解复用的概念吗， 下面是我2001年的一个贴子， http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1112015 其中的元素就是component |
| 返回顶楼 | |
