ejb这么用行吗？
有一个用于web开发的j2ee的开发框架，这样使用ejb：
ejb只服务处理事务方面的事情,
而且只有无状态sessionBean,
而且只有一个无状态的sessionBean,
sessionBean中有6、7种不同的事务方式的函数,
所有的Action通过AOP代理（用来决定Service的事务是何种）的方式去调用这个sessionBean中的一个方法（针对调用的参数不同而不同）,
然后这个方法再去调用Application Service，并将web层的参数传递过去。
这样，只有一个ejb，而且是固定的，所以开发人员不用考虑ejb的事。
布署当然也简单了。
我的疑问是：这样使用ejb有什么意思呢？
单纯从技术角度考虑，我认为是多此一举的，用Spring的Aop事务代理就能做事务，还用ejb做什么？
有人说客户想用ejb，所以这么做。
大家分析一下，这样做有什么缺点和优点呢？ 1 楼 dennis_zane 2007-10-18 完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。 2 楼 hyhongyong 2007-10-18 dennis_zane 写道完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。客户如果知道就一个ejb，能忍受这种忽悠吗？ 3 楼 dennis_zane 2007-10-18 hyhongyong 写道dennis_zane 写道完全是多此一举，不过是客户要求的就另当别论了，多忽悠点钱总是好事。客户如果知道就一个ejb，能忍受这种忽悠吗？
一个EJB怎么了？过去我参加的一个项目就是只有一个无状态SessionBean做facade，后面调用成堆的的JavaBean业务组件。 4 楼 抛出异常的爱 2007-10-18 用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽 5 楼 kenees 2007-10-18 首先，没这样用过
其次，确实重复，要么把AOP去掉，要么全部AOP 6 楼 diz 2007-10-18 多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力! 7 楼 hyhongyong 2007-10-18 抛出异常的爱 写道用一个ejb的项目我也作过。
没认为有什么不好。。。
分层清析。。
拿来就用，
不必关心事务
不必关心多个数据源
不必关心异常与回滚。
除了非要在WSAD上开发以外还没发现什么不爽
因为只用一个EJB，显然不存在事务的关联问题，那不用EJB也能解决事务问题。
多个数据源不用EJB时也不用考虑什么（除非让它们在一个事务，这样的情况一个EJB也会有问题的。）
异常与回滚是一个不用关心的地方，但Spring的Aop事务处理也能应付吧。
至于在WSAD上开发，倒不一定。可以用代理先不经过EJB，集成时再通过EJB。
我只是觉得这么用从技术上讲还不如不用。
客户布署时一看只有一个EJB，还不得急眼了。 8 楼 kenees 2007-10-18 diz 写道多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。 9 楼 hyhongyong 2007-10-18 kenees 写道diz 写道多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。 10 楼 kenees 2007-10-18 hyhongyong 写道kenees 写道diz 写道多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。看过withoutEJB的人都知道，EJB的最大用处还是分布式应用。也就是状态缓存、集群以及失败恢复机制。但如果只用无状态的，应该是集群普适场景，也就是平行加多少台机器，把代码都copy布署到机器上就oK了。用不用EJB都应该没有什么影响。
这个，这个和我问DIZ的有什么关系么？干嘛引用我的.... 11 楼 hyhongyong 2007-10-18 呵呵，顺手引上了。 12 楼 kenees 2007-10-18 另外顺便说点实在的，从混口饭吃的角度来看，EJB还是非EJB都挺好 13 楼 抛出异常的爱 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年很流行的一个方式。
14 楼 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的分布式功能也体现在这里!
15 楼 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的优势了吧! 16 楼 kyo100900 2007-10-27 如果都听客户的，程序员全会累死
