|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
raimundox 写道 你用jotm做什么？其实是contianer working，也就是提供容器的技术语义，那么如果你强调jotm写的东西的复用，其实你是在强调容器环境的复用。也正是我的论点，组件的复用要看容器。
现在我们都同意说：组件的基础设施的复用要看容器。但业务呢？你会说一个业务逻辑必须跟它的事务管理级捆绑在一起吗？如果你前后做的两个系统用不同的事务管理机制，你会认为它们之间就无法复用业务组件吗？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
这么多文字用简单的一句话概括一下就是：EJB是有标准规范的，而Spring没有。
附录中说： 引用 看到这里一定有人说，你吃饱了撑的，这么费劲容器外复用ejb，为什么不直接用spring，这样也不够pojo，每个组件都有ejb的类的继承，好，我告诉你这么做的好处，首先，虽然不够pojo，但是足够bean，因此spring来管理ejb是可以的，证明我的观点容器外使用ejb可以(赫赫，不要说偶rpwt...).其次的，当业务发展了，你的系统需要分布了，把spring去掉，拿出ejb，redeploy，ok了，延展，稳定，分布都有了，这才是复用该有的境界，改一个部署整个环境换掉，去掉lightweight的ejb container，换乘heavyweight的就是重量级。
Spring推荐是这么做的： 将服务接口用普通的Bean实现，在Spring的配置文件中定义。如果需要分布的话，Session Bean调用普通bean实现服务接口，然后修改Spring的配置文件就可以了。详细资料可参考Spring文档中有关EJB的章节。 好处：测试简单，需要分布时，扩展一层EJB而不需要重写业务逻辑。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 你用jotm做什么？其实是contianer working，也就是提供容器的技术语义，那么如果你强调jotm写的东西的复用，其实你是在强调容器环境的复用。也正是我的论点，组件的复用要看容器。
现在我们都同意说：组件的基础设施的复用要看容器。但业务呢？你会说一个业务逻辑必须跟它的事务管理级捆绑在一起吗？如果你前后做的两个系统用不同的事务管理机制，你会认为它们之间就无法复用业务组件吗？ 什么是组件的基础设施？component architecture是一个技术和业务soc，超过这个就是doamin specified framework或者platform的事情了，ejb是业务框架吗？不是！Spring是业务框架吗？不是！他们职责是什么，技术语义复用，注意不是技术机制。 至于具体使用事务机制，我仍然强调这和语义是两会事，机制可以用jdbc,jta,jotm等等什么来实现，但是业务组件可能在系统A里需要requiredNew的transanction语义，而在系统B里则是required就好了，这合机制没关系，jta，jdbc都可以很好的实现这个语义。 因此不同机制不是复用的障碍，不同语义才是，你把componentA实现成requiredNew的，那么复用到required的语义就有问题。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 因此不同机制不是复用的障碍，不同语义才是，你把componentA实现成requiredNew的，那么复用到required的语义就有问题。
难道你会在任何一个EJB的业务逻辑中说“这个EJB需要requiredNew的事务语义”吗？难道“业务组件使用什么事务语义”不是一种声明性基础设施、倒是一种业务逻辑吗？ |
| 返回顶楼 | |
|
发表时间：2004-09-20
jeffrey_he 写道 这么多文字用简单的一句话概括一下就是：EJB是有标准规范的，而Spring没有。
附录中说： 引用 看到这里一定有人说，你吃饱了撑的，这么费劲容器外复用ejb，为什么不直接用spring，这样也不够pojo，每个组件都有ejb的类的继承，好，我告诉你这么做的好处，首先，虽然不够pojo，但是足够bean，因此spring来管理ejb是可以的，证明我的观点容器外使用ejb可以(赫赫，不要说偶rpwt...).其次的，当业务发展了，你的系统需要分布了，把spring去掉，拿出ejb，redeploy，ok了，延展，稳定，分布都有了，这才是复用该有的境界，改一个部署整个环境换掉，去掉lightweight的ejb container，换乘heavyweight的就是重量级。
Spring推荐是这么做的： 将服务接口用普通的Bean实现，在Spring的配置文件中定义。如果需要分布的话，Session Bean调用普通bean实现服务接口，然后修改Spring的配置文件就可以了。详细资料可参考Spring文档中有关EJB的章节。 好处：测试简单，需要分布时，扩展一层EJB而不需要重写业务逻辑。 这是两种思路，我是把spring作为lightweight ejb container provider来对待的，那么一旦需要heavyweight，更换容器。而spring强调在spring里用ejb。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 贫语义这里指贫技术语义，spring没有提供任何的现有技术语义，而把这部分交给developer自己去处里。我说spring贫语义，不是说他没有语义。
不理解什么叫技术语义。 业务处理本来就是developer自己要干的事情，用ejb也好，spring也好，大家都管不到这里。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
gigix 写道 raimundox 写道 因此不同机制不是复用的障碍，不同语义才是，你把componentA实现成requiredNew的，那么复用到required的语义就有问题。
难道你会在任何一个EJB的业务逻辑中说“这个EJB需要requiredNew的事务语义”吗？难道“业务组件使用什么事务语义”不是一种声明性基础设施、倒是一种业务逻辑吗？ gigix兄，你问我的是：你会说一个业务逻辑必须跟它的事务管理级捆绑在一起吗？如果你前后做的两个系统用不同的事务管理机制，你会认为它们之间就无法复用业务组件吗？ 第一句其实我没有回答，我答得是第二句，强调机制不同和语义不同的问题。 至于第一个，我想还是那句话，组件不该有技术代码，这是理想情况。而且我从来没说过ejb的业务逻辑中说，而是该在外说，在容器里说，在部署里说，也是我为什么说deployer重要的原因，事务scope是他们界定的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
hehe,总算看明白了。
那个不叫技术语义，而是技术约束。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
charon 写道 raimundox 写道 贫语义这里指贫技术语义，spring没有提供任何的现有技术语义，而把这部分交给developer自己去处里。我说spring贫语义，不是说他没有语义。
不理解什么叫技术语义。 业务处理本来就是developer自己要干的事情，用ejb也好，spring也好，大家都管不到这里。 比如说事务，那么语义有什么？ejb给了一个集合：NotSupported,Supports,Required,RequiredNew,Mandatory,Never,Bean Managed 其实这是ejb事务争用的模型，也是ejb事务争用的语义(我想我偏爱语义这个词大概是受林星的影响，林你在看吗：）)，和实现机制没关系。这就是组件的技术语义。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 而且我从来没说过ejb的业务逻辑中说，而是该在外说，在容器里说，在部署里说，也是我为什么说deployer重要的原因，事务scope是他们界定的。
好了，现在我们都同意：组件的业务逻辑不应该涉及“要不要事务管理、要什么事务管理”这样的基础设施。那么我请问你，既然组件的业务逻辑不应该涉及这些，难道把组件模型的技术架构跟这些玩意捆绑在一起就显得很合理了吗？如果可选的话，难道POJO不是更自然的选择吗？ |
| 返回顶楼 | |
