|
锁定老帖子 主题：ejb这么用行吗？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (4) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-10-18
hyhongyong 写道 kenees 写道 diz 写道 多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。 这个，这个和我问DIZ的有什么关系么？干嘛引用我的.... |
| 返回顶楼 | |
|
发表时间：2007-10-18
呵呵，顺手引上了。
|
| 返回顶楼 | |
|
发表时间：2007-10-18
另外顺便说点实在的，从混口饭吃的角度来看，EJB还是非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年很流行的一个方式。 |
| 返回顶楼 | |
|
发表时间：2007-10-22
kenees 写道 hyhongyong 写道 kenees 写道 diz 写道 多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。 这个，这个和我问DIZ的有什么关系么？干嘛引用我的.... 从技术角度什么都有可能的,使用ejb还是其他的技术完全是求一个折中方案,你及时抛开所有的高级语言直接用汇编写,都可以实现所有的需求! 问题不是习惯用什么,web service是一种方法,但是当你使用了ejb后你所有的业务接口就都具备了ws业务多简单,ejb的分布式功能也体现在这里! |
| 返回顶楼 | |
|
发表时间：2007-10-22
hyhongyong 写道 kenees 写道 diz 写道 多半是全局事务和全局远程调用!这两点太吸引了!抛开这两点,ejb从技术角度应该没有太大的吸引力!
请问DIZ，“全局事务”是否说得是JTA？如果是，不用EJB自己也可以利用JTA，JTA是容器提供的而非EJB提供的。另外，对于远程调用EJB确实是挺好的，不过现在多数企业都流行WEB SERVICE。 但是我仔细阅读过Dannes Rmei的在TSS上的一偏文章,其中阐述的一个观点是在服务器上保存状态是一个非常ugly的设计,我没有仔细验证这个结论的正确性,但是本人对状态缓纯也持保留意见.至于集群,我没弄过,但是似乎已经不是ejb的优势了吧! |
| 返回顶楼 | |
|
发表时间：2007-10-27
如果都听客户的，程序员全会累死
|
| 返回顶楼 | |
