SSH与EJB 比较

SSH完全的开源产品，如果用SSH就必然会用到大量的开源的东东，从数据库到逻辑到控制到前端，开源产品大拼装，

其中SSH中的三大核心，Struts相当于JSF，spring相当于EJB，hibernate相当于JPA，

具体反映到IDE对于两种框架的支持上，本人用的是netbeans，对经典的JAVAEE支持的非常好，所有的配置文件都集成到了IDE中，甚至还包括了一个中文免费的EJB容器：Glassfish，反观SSH，虽然也有大力支持，但是配置起来相对繁琐，不过也还好，总之，SSH和经典JAVAEE之间确实是相互补充，共同进步的关系。

SSH优点：运行速度快，开发调试一点就来

        缺点：配置显复杂了些，拼装起来有种大杂烩的感觉

经典JAVAEE优点：集成度高，整体感强

        缺点：EJB容器相对对电脑要求高些，开发调试速度慢

 

 

SSH是标准的  面向对象框架。这里的标准有两层含义，一指它是一个非常合格的面向对象框架，一指它近乎业界的标准。一个 一直被认为与它有点冲突的真正的标准是EJB。

EJB更像一个企业级应用API。它的目标是在应用程序服务器与企业应用之间建立一个通信层。也就是说它在服务器与应用之间插入了一个协议。两者之间则通过协议进行通信。通过协议进行通信的好处不言而喻，它为两者的独立发展提供了一个非常牢固的基础。

这个基础的来源便在于抽象化：EJB通过将应用需求进行高度，标准化的抽象，重新定义了几乎所有（至少它在尝试）的应用程序服务。因为只有在这些服务得到成功的抽象以后，服务器开发者才能得到它真正的自由，应用程序开发者也才能得到它的。在这个意义上，SSH与之相比，实在是九牛一毛，不值得比。

虽然现在的SPRING现在庞大无比，但是一开始的SSH其实是一个最简单的OO框架：它只是简单地处理了一下分别处于两头的持久层与表现层并在中间层上提供了一个简单的对象创建器（IOC）。我把这个一开始的SSH当成我们现在讨论的对象。因为即使SPRING提供再多的东西，也无法改变SSH作为一个整体在系统开发中的地位：一个面向对象的支撑器。

等等，一个面向对象的支撑器？

看到这里，还会有人想把它与EJB相比吗？（当然，如果把现在的SPRING整个服务体系也搬进来的话，一定要比还是有办法的）。因为对象与服务显然是两个完全不同的概念。对象只是服务的一种。EJB的假设是对象这种东西应该是由应用程序开发者自己去处理的，平台不应该处理这样的问题。因为它属于用户程序领域（这是SPRING之所以能向J2EE斜插一刀的原因）。另一方面，对象服务本来就比较贴“身”，平台的确不太便于处理这样的服务？