|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
我算是看明白了。说来说去，楼主的意思还是说，如果用spring之类的轻量级架构，自己要做的事情太多；如果用EJB，厂商提供了很多东西，自己要做的少得多。对吧？
|
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 我算是看明白了。说来说去，楼主的意思还是说，如果用spring之类的轻量级架构，自己要做的事情太多；如果用EJB，厂商提供了很多东西，自己要做的少得多。对吧？
我倒是认为：他的文章说了不少有价值的观点。无论正确与否，都无法像你现在这样一言以蔽之。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
firebody 写道 楼主跟我们一般的“复用”概念是不一致的！
讨论起来，估计将会是一场大战。 容器内的复用 与 不依赖任何外部容器的复用 是完全不同的概念 楼主的： component architecture 这一部分就暴露了楼主对于“复用”概念的理解偏差！ 你说EJB的Bean可以跟Spring的POJO相比，那么请你看看EJB的sessionbean的超类是什么！这个超类是干什么用的！（继承也是依赖，别忘了哦） 如果你的项目需要移植到非EJB的环境中，可行吗？NO！当然，你可以尽量说服老板使用EJB，这样可以让老板大投入，大出血。 POJO的复用，在于它是一个纯粹的不依赖外部的bean。你可以部署在spring，也可以是pico。 至于说，事务，安全，等等。这些固然是EJB的特点，但如今这些咚咚都有了轻量级的开源项目支持，以后，EJB的这些优势也会逐渐失去。 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。 至于SessionBean，那没什么，写过rmi的人都知道，Remote的对象你不做stub和skeleton，不去exportObject也不会成为remote对象，一样可以像bean来用，虽然不够pojo，但是足够bean，并不会因为继承而有了什么额外的东西。 有了轻量级实现，但是语义不统一，当然你可以说不统一也没什么关系，不过我认为统一的语义更有意义. |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。
如果我有办法选择是否给业务组件加装事务管理，有办法选择加装哪种事务管理，我干吗还要选择一个绑死的事务管理机制？这不是需要不需要的问题，而是能不能灵活选择的问题。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。
如果我有办法选择是否给业务组件加装事务管理，有办法选择加装哪种事务管理，我干吗还要选择一个绑死的事务管理机制？这不是需要不需要的问题，而是能不能灵活选择的问题。 对啊！ 灵活性与复用性，与开发效率是矛盾呀。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
庄表伟 写道 gigix 写道 raimundox 写道 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。
如果我有办法选择是否给业务组件加装事务管理，有办法选择加装哪种事务管理，我干吗还要选择一个绑死的事务管理机制？这不是需要不需要的问题，而是能不能灵活选择的问题。 对啊！ 灵活性与复用性，与开发效率是矛盾呀。 没错，如果我每次都要从头开始学用JOTM，那它的灵活性确实和开发效率是矛盾。但如果我有一个template application呢？至于复用性，我不认为它和开发效率是矛盾，不然我干吗还要追求复用性？可复用对于客户来说是没意义的，要是它再对开发人员也没意义，谁在乎它？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。
如果我有办法选择是否给业务组件加装事务管理，有办法选择加装哪种事务管理，我干吗还要选择一个绑死的事务管理机制？这不是需要不需要的问题，而是能不能灵活选择的问题。 ejb也可以选择事务管理，jdbc，jta但是他有一些额外的事物语义，比如required,requiredNew。因此事务机制和事务语义是两种不同的概念。比如一个requiredNew的事务语义，可以用jdbc实现，可以用jta实现，这是机制差异，不是语义差异。因此这也不是灵活性的问题，而是容器语义的问题。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 庄表伟 写道 gigix 写道 raimundox 写道 对，我的复用的理解是建立在component architecture的技术和业务分离上的，因此组件复用不可能脱离容器来谈，还是那个例子，一个没有任何事物处理代码的组件怎么处理事务？依赖容器。
如果我有办法选择是否给业务组件加装事务管理，有办法选择加装哪种事务管理，我干吗还要选择一个绑死的事务管理机制？这不是需要不需要的问题，而是能不能灵活选择的问题。 对啊！ 灵活性与复用性，与开发效率是矛盾呀。 没错，如果我每次都要从头开始学用JOTM，那它的灵活性确实和开发效率是矛盾。但如果我有一个template application呢？至于复用性，我不认为它和开发效率是矛盾，不然我干吗还要追求复用性？可复用对于客户来说是没意义的，要是它再对开发人员也没意义，谁在乎它？ 你用jotm做什么？其实是contianer working，也就是提供容器的技术语义，那么如果你强调jotm写的东西的复用，其实你是在强调容器环境的复用。也正是我的论点，组件的复用要看容器。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 庄表伟 写道 对啊！
灵活性与复用性，与开发效率是矛盾呀。 没错，如果我每次都要从头开始学用JOTM，那它的灵活性确实和开发效率是矛盾。但如果我有一个template application呢？至于复用性，我不认为它和开发效率是矛盾，不然我干吗还要追求复用性？可复用对于客户来说是没意义的，要是它再对开发人员也没意义，谁在乎它？ 对不起，是断句问题。 应该是这样说：灵活性与“复用性、开发效率”是矛盾呀。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
灵活性与复用性，与开发效率是矛盾呀。
这点，我赞同！ 但并不是绝对矛盾的。在某些时候，开发效率会跟复用性成正比。当然，这可能发生在产品化，以某些组件为核心迅速开发多种领域下的产品的情况下，这是有可能的！ |
| 返回顶楼 | |
