2007-10-18

ejb这么用行吗？

有一个用于web开发的j2ee的开发框架，这样使用ejb：

ejb只服务处理事务方面的事情,
而且只有无状态sessionBean,
而且只有一个无状态的sessionBean,
sessionBean中有6、7种不同的事务方式的函数,
所有的Action通过AOP代理（用来决定Service的事务是何种）的方式去调用这个sessionBean中的一个方法（针对调用的参数不同而不同）,
然后这个方法再去调用Application Service，并将web层的参数传递过去。

这样，只有一个ejb，而且是固定的，所以开发人员不用考虑ejb的事。
布署当然也简单了。

我的疑问是：这样使用ejb有什么意思呢？
单纯从技术角度考虑，我认为是多此一举的，用Spring的Aop事务代理就能做事务，还用ejb做什么？
有人说客户想用ejb，所以这么做。

大家分析一下，这样做有什么缺点和优点呢？
评论
kyo100900 2007-10-27
如果都听客户的，程序员全会累死
diz 2007-10-22
hyhongyong 写道
kenees 写道
diz 写道
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!


请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。
看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。



但是我仔细阅读过Dannes Rmei的在TSS上的一偏文章,其中阐述的一个观点是在服务器上保存状态是一个非常ugly的设计,我没有仔细验证这个结论的正确性,但是本人对状态缓纯也持保留意见.至于集群,我没弄过,但是似乎已经不是ejb的优势了吧!
diz 2007-10-22
kenees 写道
hyhongyong 写道
kenees 写道
diz 写道
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!


请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。
看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。


这个，这个和我问DIZ的有什么关系么？干嘛引用我的....



从技术角度什么都有可能的,使用ejb还是其他的技术完全是求一个折中方案,你及时抛开所有的高级语言直接用汇编写,都可以实现所有的需求!

问题不是习惯用什么,web service是一种方法,但是当你使用了ejb后你所有的业务接口就都具备了ws业务多简单,ejb的分布式功能也体现在这里!
抛出异常的爱 2007-10-18
hyhongyong 写道
抛出异常的爱 写道
用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽

因为只用一个EJB，显然不存在事务的关联问题，那不用EJB也能解决事务问题。
多个数据源不用EJB时也不用考虑什么（除非让它们在一个事务，这样的情况一个EJB也会有问题的。）
异常与回滚是一个不用关心的地方，但Spring的Aop事务处理也能应付吧。

至于在WSAD上开发，倒不一定。可以用代理先不经过EJB，集成时再通过EJB。

我只是觉得这么用从技术上讲还不如不用。

客户布署时一看只有一个EJB，还不得急眼了。


1.先要考虑管不管用，如果管用，则用哪种就看哪种的方案：合乎公司，客户利益，而不是考虑程序的想法（这个条件要排到至少20位之后）
2.多个数据源，在去年6月份时还是ejb比spring简单一点的。（当时的人员对spring的理解不是不高。都是通过DEMO，而DEMO中没有双数据源的例子，而ejb成功的例子很多）
3.EJB作了理？。。。不明白原理，另当时没想到开发很痛苦
4.如果你布署时用了十多个EJB客户会更急眼。。。跑都跑不动。
5.用一个ejb是2004－2005年很流行的一个方式。
kenees 2007-10-18
另外顺便说点实在的，从混口饭吃的角度来看，EJB还是非EJB都挺好
hyhongyong 2007-10-18
呵呵，顺手引上了。
kenees 2007-10-18
hyhongyong 写道
kenees 写道
diz 写道
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!


请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。
看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。


这个，这个和我问DIZ的有什么关系么？干嘛引用我的....
hyhongyong 2007-10-18
kenees 写道
diz 写道
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!


请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。
看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。
kenees 2007-10-18
diz 写道
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!


请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。
hyhongyong 2007-10-18
抛出异常的爱 写道
用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽

因为只用一个EJB，显然不存在事务的关联问题，那不用EJB也能解决事务问题。
多个数据源不用EJB时也不用考虑什么（除非让它们在一个事务，这样的情况一个EJB也会有问题的。）
异常与回滚是一个不用关心的地方，但Spring的Aop事务处理也能应付吧。

至于在WSAD上开发，倒不一定。可以用代理先不经过EJB，集成时再通过EJB。

我只是觉得这么用从技术上讲还不如不用。

客户布署时一看只有一个EJB，还不得急眼了。
diz 2007-10-18
多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
kenees 2007-10-18
首先，没这样用过
其次，确实重复，要么把AOP去掉，要么全部AOP
抛出异常的爱 2007-10-18
用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽
dennis_zane 2007-10-18
hyhongyong 写道
dennis_zane 写道
完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。
客户如果知道就一个ejb，能忍受这种忽悠吗？

一个EJB怎么了？过去我参加的一个项目就是只有一个无状态SessionBean做facade，后面调用成堆的的JavaBean业务组件。
hyhongyong 2007-10-18
dennis_zane 写道
完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。
客户如果知道就一个ejb，能忍受这种忽悠吗？
dennis_zane 2007-10-18
完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

hyhongyong
搜索本博客
博客分类
最近加入圈子
最新评论
评论排行榜