|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
Java Bean就是很好的语义约定。还需要别的什么约定吗？
|
| 返回顶楼 | |
|
发表时间：2004-09-20
所谓的POJO就是没有任何限制、约束的普通Java对象，Pico和Spring都做不到这一点，唯一的办法是利用AOP改良这些框架
|
| 返回顶楼 | |
|
发表时间：2004-09-20
charon 写道 raimundox 写道 你用spring的事务语义还不是要绑死在spring上？所然可以替换语义实现，但是语义等价是必须的。关键还是语义，我很赞成在ejb的语义下把spring做为实现技术，spring缺少的是一套公认的完整的语义支持。 而ejb3开放语义实现机制其实是一个很好的契机，也是我对ejb最后的希望。如果可能，将会是lightweight ejb container和heavyweight ejb container并存 兄弟，你没发现你的立场在变化？spring从"贫语义"变成了"缺少的是一套公认的完整的语义支持"。 完整与否我不知道，因为没看到不完整的例子。ejb和spring相比，我看是spring相对更加完整一点点。至少spring的服务范围要大于ejb。 至于公认，这个就更加难说了。很多时候，公认归公认，是不是使用就是另外一回事情。 我仍然认为spring并没有规定语义，因为大部分时候语义是我们自己实现的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
其实，spring缺少的是一个相对稳定的明确的语义。
ejb一路下来，因为走的是先规范再实现的方式，规范是相对稳定的。而spring走的正好相反，是一个工程化的路子，只有当一个特性经历几个版本沉淀下来之后，才可能被开发组、被社区认定为spring的必备而且稳定的特性。 语义一直在那里摆着，但是这个摆着的语义，经常的在晃动。所以，每一次spring发布新版本，千万要仔细阅读changelog，hehe. |
| 返回顶楼 | |
|
发表时间：2004-09-20
potian 写道 庄表伟 写道 to:potian,gigix
“可用”和“可复用”是两个概念。 POJO在哪里都可以再次使用，一个简单的对象而已。 但是要能够复用，不是能够把这POJO new出来就算是用起来了。 你认为我不理解复用的概念吗， 下面是我2001年的一个贴子， http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1112015 其中的元素就是component 这篇文章我仔细看了两遍，下面说说我的理解。 1、框架+组件(元素)+具体代码=等于一个实际的系统 2、框架可以认为是一组抽象基类，元素需要扩展这些基类，才能够被具体使用。 3、具体代码只需要使用这些元素，就可以构建实际的系统。 4、元素需要了解框架，否则无法发挥作用。 5、具体代码不需要了解框架，它只需要使用元素提供的功能。 那么，你想要说的，是不是这些元素就具有可重用性呢？ 这些元素不是需要通过扩展框架中的抽象类来实现的吗？ 这种扩展，能不能不依赖于框架，而称之为POJO呢？ potian，你说POJO的复用性肯定要比EJB好，但是你举的例子，是不是POJO呢？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 Java Bean就是很好的语义约定。还需要别的什么约定吗？
javaBean并没有规定什么组件作，什么容器作，当然这是他的优点，可以任意的扩展，因此我倾向把ejb3称为enhanced java bean，就是一个有容易交互语义扩展的javabean，其实我们用spring做的时候，也是在自己增强javaBean的容器相关语义。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 我仍然认为spring并没有规定语义，因为大部分时候语义是我们自己实现的。 这个很简单，你举一个反例就可以说明问题了。 但是在这里，我看ejb相比spring并没有优势。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
这也是个价值取向的问题。我不觉得“规定什么组件作，什么容器作”很有价值。一件事情我认为它是业务逻辑，我可以把它放在组件里做；如果它在另一个环境下具有了横切性，我认为它是基础设施，我可以把它放在容器里做。规定死了有什么好处吗？
|
| 返回顶楼 | |
|
发表时间：2004-09-20
agilecat 写道 我的看法:
1. ejb3 是模仿spring建立的体系结构,ejb3跟spring的关系就像jdo跟hibernate的关系,老的ejb体系已经垂死,ejb3使轻量级容器有了更多选择. 2. 到了ejb3时代,有可能spring修改符合ejb3,也有可能部分中间件厂商拿spring作内核来实现ejb3. 就像hibernate和entity bean的关系一样. 3. ejb3仍然会是j2ee的核心模块,但由于spring的开放性,用户不再会对ejb3的需求付费,用户付费的核心是分布式事务. 4. 纯中间件服务器的利润会暴跌,因为许多应用不需要分布式事务,主流中间件厂商会把业务核心转向portal,eai,数据仓库等方向. 我同意这样的观点。我本来想写一个帖子阐述这样的观点的。 其实在中国，把关注力转向商业逻辑元件和商业逻辑框架，显得意义更加重大。因为中国在全球IT产业链处于底层，在技术层面上无法改变追随者的地位。就算有人能够做出来优秀的开源技术框架，但是如果英文水平不足够好的话，还是没有办法普及到全球。但是商业逻辑框架就不同，中国的软件公司和外国的软件公司站在同一起跑线，本土的公司甚至还有很多优势。我的主张就是采用流行的可靠的开源技术框架，例如Hibernate/Spring/Webwork2之类的就可以了，没有必要非在技术上较真，而把资源投入到钻研行业业务上，要做到比客户还精通业务，把业务抽象出来好的商业逻辑框架。这才是软件公司的核心竞争力。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 这也是个价值取向的问题。我不觉得“规定什么组件作，什么容器作”很有价值。一件事情我认为它是业务逻辑，我可以把它放在组件里做；如果它在另一个环境下具有了横切性，我认为它是基础设施，我可以把它放在容器里做。规定死了有什么好处吗？
还是老问题，没有约定，就不好复用，如果把一个自己负责事务的组件放到不允许自己控制的容器内会怎么？这就是组件违反容器约定的冲突。 当然价值取向也是一个问题，从95年起，我就觉得component market很好，今天我仍然认为它很好。可配的容器，约定清晰的组件，都是这一价值的体现。 |
| 返回顶楼 | |
