用过EJB2.x的人估计对EJB带来的痛苦记忆犹新。一大堆的接口、一大堆的规定、一大堆的配置，痛苦不堪的调试……。因此，“我们是否需要EJB2”这个答案还是比较显然，那就是我们绝大多数系统不需要，除非你的系统真的是分布式计算，迫不得已需要用EJB2。
现在EJB3已经出炉了，开发的复杂度确实大大地减少，已经和编写普通Javabean无异，部署也非常方便。那么我们的系统是否需要采用EJB3呢？
我想用另一个问题来回答这个问题。那就是：我们要EJB3做什么？
通常EJB能提供如下用途：分布式计算、可配置的事务管理、OR-Mapping，容器管理的安全性等。
如果你的系统确实有分布式计算，或者把计算逻辑隐藏在防火墙的内部，那么EJB3确实有用武之地。
如果没有这个需求，我认为我们的系统没有必要用EJB3。因为EJB和servlet毕竟在不同的容器中运行，大多数时候不同的容器有各自的classloader。而我们的servlet需要引用EJB的接口，实体Bean；servlet和EJB会公用很多的公共包...；这种复杂的状况导致打EAR包时非常麻烦，初级开发人员较难掌控。
如果你想利用EJB容器的事务管理能力，我觉得Spring完全可以替代EJB容器。
如果你想利用EJB容器管理的安全性，我的观点是，容器管理的安全性完全不实用，至少在我们的系统中没法用。
如果你想用EntityBean的OR-Mapping，那么用Hibernate完全可以替代。况且EJB3的Entitybean接口就是从hibernate继承过来的。
所以我觉得95%以上的系统，采用JSF（或Struts或其他）+Spring+hibernate还是最佳选择。原因很简单，这种结构的代码简单、好维护。
现在EJB3已经出炉了，开发的复杂度确实大大地减少，已经和编写普通Javabean无异，部署也非常方便。那么我们的系统是否需要采用EJB3呢？
我想用另一个问题来回答这个问题。那就是：我们要EJB3做什么？
通常EJB能提供如下用途：分布式计算、可配置的事务管理、OR-Mapping，容器管理的安全性等。
如果你的系统确实有分布式计算，或者把计算逻辑隐藏在防火墙的内部，那么EJB3确实有用武之地。
如果没有这个需求，我认为我们的系统没有必要用EJB3。因为EJB和servlet毕竟在不同的容器中运行，大多数时候不同的容器有各自的classloader。而我们的servlet需要引用EJB的接口，实体Bean；servlet和EJB会公用很多的公共包...；这种复杂的状况导致打EAR包时非常麻烦，初级开发人员较难掌控。
如果你想利用EJB容器的事务管理能力，我觉得Spring完全可以替代EJB容器。
如果你想利用EJB容器管理的安全性，我的观点是，容器管理的安全性完全不实用，至少在我们的系统中没法用。
如果你想用EntityBean的OR-Mapping，那么用Hibernate完全可以替代。况且EJB3的Entitybean接口就是从hibernate继承过来的。
所以我觉得95%以上的系统，采用JSF（或Struts或其他）+Spring+hibernate还是最佳选择。原因很简单，这种结构的代码简单、好维护。
