EJB+IBatis这种做法合理吗？

08-06-24 winadobe

由于业务量增长，出于长远考虑，需要将一套Spring+IBatis的系统改成EJB架构的系统，主要是想将不同业务封装到EJB中，分布式部署，容易对繁忙的业务做水平伸缩。呵呵，以前真的不懂这些，一直认为spring足矣，终于明白了EJB的巨大用途。更多的好处等我做完了项目再总结。
问题是存在很多复杂SQL语句，想重用IBatis DAO部分，业务移植到Session Bean中，这样一来EJB容器带来的很多好处就都没了，比如事务都要自己控制，唯一好处就是把业务做成了一个分布式组件，可以分布部署。
感觉有点不伦不类的，请帮忙分析一下利弊，或者该怎样做得更合理一些！该批评的就批评！多谢了！

banq

2008-06-25 15:25

从技术上讲是可以的。

关键风险问题不是技术，而是你当初编程思路。

需要搞清楚你的负载压力在哪里？在应用服务器tomcat/j2ee服务器上，可以使用EJB集群；如果当初是数据库编程思路，使用SQL完成复杂的业务计算，那么负载显然在数据库上，使用EJB集群就无法解决问题了。

如果你当初选择Spring时，就能够明白这些道理，相信现在移植就很轻松，否则，可能你的系统需要重写。这就是我在这里一直强调DDD和OO设计的目的所在。

有些人一直这句话：80%的项目是中小型项目，因此不需要EJB。
需要不需要与懂不懂EJB是两个问题，如果因为80%项目不需要EJB，就认为不需要了解EJB，以及在做架构时，根本不知道EJB存在，那么很显然范了无知无畏的毛病。

我以前一直在说这么一个道理，人们不可能预测未来，有的只是对现有结果总结，是马后炮定理，马后炮定理根本不能指导我们实践。80%项目不需要分布式计算是一个现实结果，但是你怎么知道你还没做出来的项目将来就肯定属于这个80%的范围内？

打个通俗比喻：炒股都知道要抄底，但是底部是走出来的，也就是说：当涨了以后，回头看看那时是底部，但是那时你知道当时是底部吗？就象现在你知道股票2800点是底部吗？

所以，连马后炮定理这样基本逻辑都没有想明白的人，根本就不适合炒股和搞软件。以前在Jdon网站和我争论EJB的不少人属于这类。

在没有人敢打100%包票说本项目将来肯定不需要高性能，不需要分布式计算情况下，可伸缩性是项目开始之初架构必须考虑的一个因素，至少有一个方案：将来能否平滑过渡到分布式环境，否则一个规模重写一套软件老路。

再说了：使用java这样容器性解释语言，它和C++等拼的不是单机性能，而是群计算能力，就象，我们中国人一个单个人体质不如西方人，那么我们一群人就可以对付他们，所以，我们讲究集体的力量，Java也是一个讲究集体力量的语言平台。

只有了解这些，才真正悟java之道。

著名社交网站LinkedIn的Java架构技术

http://www.jdon.com/jivejdon/thread/34214.html

[该贴被banq于2008-06-25 17:20修改过]

winadobe

2008-07-03 02:39

非常感谢斑竹的指点，的确如您所讲的Java带给我们群计算能力，EJB技术优势正体现在这里。
从一开始我个人也担心过以后业务增长单机无法应付，但也没人重视过！
的确很多人不懂EJB，当然也包括我，而且也不重视EJB，很多人拿EJB跟Spring来比较，但那都是在单机环境下的比较，没有什么意义！两个都非常优秀，只是应用场合不一样而已。
在该项目的改造中没有抛弃Spring，是把EJB跟Spring结合起来了，在EJB3中利用了Spring提供的SpringBeanAutowiringInterceptor很容易整合起来。Spring担任着整合第三方框架的任务（例如IBatis），Session Bean提供Facade。
将几个关键业务分别做成了EJB组件，对压力较大的业务做了集群，现在的状况得到了很大改善：我们很清楚知道哪些业务繁忙，从而对繁忙业务增加服务器，增加服务器的代价很小，控制的粒度可以很细，比对整个应用做Web集群效果明显很多；将不同业务做成EJB组件以后，层次结构清晰了很多，也降低了耦合度，之前一个应用包括了所有业务，项目组很多人一下子难以理清楚；
呵呵，接下来还有好多事情要做，希望能在实际应用中更深入地理解EJB