开源的SSH框架优缺点分析

开源是3个框架共有的优势

Struts2框架（MVC框架）的优势以下：

1） 实现了MVC模式，层次结构清晰，使程序员只需关注业务逻辑的实现；

2） 丰富的标签库，大大提升了开发的效率；

3） Struts2提供丰富的拦截器实现

3） 经过配置文件，就能够掌握整个系统各个部分之间的关系；

4） 异常处理机制，只需在配置文件中配置异常的映射，便可对异常作相应的处理；

Spring框架的优势以下：

1） 无入侵性（在业务逻辑代码中感受不到Spring框架的存在）；

2） 各个组件之间的耦合极为松散；

3） 无需程序员本身实现singleton模式；

4） 经过AOP，能够实现事务管理和日志管理；

5） 整合其余的框架，如：struts框架和hibernate框架；

Hibernate框架（ORM框架）的优势以下：

1） 对象/关系数据库映射（ORM）， 使用时只需操纵对象，使开发更加面向对象化；

2） 无入侵性；

3） 简洁的HQL语句，减小了JDBC与SQL操做数据库的代码量；

4） 移植性好；

缺点以下：

1） 对批量更新，删除的支持很差；

什么是SSH2框架。好处在哪里？

SSH2框架：

具体来讲应该是：struts2.0+spring3.2+hirbnate2.5
典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工做放在中间层处理。客户端不直接与数据库交互，而是经过组件与中间层创建链接，再由中间层与数据库交互。

表现层是传统的JSP技术，自1999年问世以来，通过多年的发展，其普遍的应用和稳定的表现，为其做为表现层技术打下了坚实的基础。

中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为如下几种。

Web层，就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层做组织表现，该系统的MVC框架采用Struts。

Service层（就是业务逻辑层），负责实现业务逻辑。业务逻辑层以DAO层为基础，经过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。

DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操做。

PO，持久化对象。经过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操做数据库，该系统采用Hibernate做为ORM框架。

Spring的做用贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。

一个良好的框架可让开发人员减轻从新创建解决复杂问题方案的负担和精力；它能够被扩展以进行内部的定制化；而且有强大的用户社区来支持它。框架一般能很好的解决一个问题。然而，你的应用是分层的，可能每个层都须要各自的框架。仅仅解决UI问题并不意味着你可以很好的将业务逻辑和持久性逻辑和UI 组件很好的耦合。



不能否认，对于简单的应用，采用ASP或者PHP的开发效率比采用J2EE框架的开发效率要高。甚至有人会以为：这种分层的结构，比通常采用JSP + Servlet的系统开发效率还要低。

笔者从一下几个角度来阐述这个问题。

— 开发效率：软件工程是个特殊的行业，不一样于传统的工业，例如电器、建筑及汽车等行业。这些行业的产品一旦开发出来，交付用户使用后将不多须要后续的维护。但软件行业不一样，软件产品的后期运行维护是个巨大的工程，单纯从前期开发时间上考虑其开发效率是不理智的，也是不公平的。众所周知，对于传统的ASP和 PHP等脚本站点技术，将整个站点的业务逻辑和表现逻辑都混杂在ASP或PHP页面里，从而致使页面的可读性至关差，可维护性很是低。即便须要简单改变页面的按钮，也不得不打开页面文件，冒着破坏系统的风险。但采用严格分层J2EE架构，则可彻底避免这个问题。对表现层的修改即便发生错误，也绝对不会将错误扩展到业务逻辑层，更不会影响持久层。所以，采用J2EE分层架构，即便前期的开发效率稍微低一点，但也是值得的。

— 需求的变动：以笔者多年的开发经验来看，不多有软件产品的需求从一开始就彻底是固定的。客户对软件需求，是随着软件开发过程的深刻，不断明晰起来的。所以，经常遇到软件开发到必定程度时，因为客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现须要改变时，是否能够尽量多地保留软件的部分，尽量少地改变软件的实现，从而知足客户需求的变动？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但毫不与任何具体的业务逻辑组件耦合，只与接口耦合；一样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即便软件的部分发生改变，其余部分也尽量不要改变。

注意：即便在传统的硬件行业，也有大量的接口规范。例如PCI接口、显卡或者网卡，只要其遵照PCI的规范，就能够插入主板，与主板通讯。至于这块卡内部的实现，不是主板所关心的，这也正是面向接口编程的好处。假如须要提升电脑的性能，须要更新显卡，只要更换另外一块PCI接口的显卡，而不是将整台电脑抛弃。若是一台电脑不是采用各类接口组合在一块儿，而是作成整块，那将意味着即便只须要更新网卡，也要放弃整台电脑。一样，对于软件中的一个个组件，当一个组件须要重构时，尽可能不会影响到其余组件。实际上，这是最理想的状况，即便采用目前最优秀的架构，也会有或多或少的影响，这也是软件工程须要努力提升的地方。

技术的更新，系统重构：软件行业的技术更新很快，虽然软件行业的发展不快，但小范围的技术更新特别快。一旦因为客观环境的变化，不得不更换技术时，如何保证系统的改变最小呢？答案仍是选择优秀的架构。

在传统的Model 1的程序结构中，只要有一点小的需求发生改变，将意味着放弃整个页面。或者改写。虽然前期的开发速度快，除非能够保证之后永远不会改变应用的结构，不然不要采用Model 1的结构。

采用Hibernate做为持久层技术的最大的好处在于：能够彻底以面向对象的方式进行系统分析、系统设计。

DAO模式须要为每一个DAO组件编写DAO接口，同时至少提供一个实现类，根据不一样须要，可能有多个实现类。用Spring容器代替DAO工厂

一般状况下，引入接口就不可避免须要引入工厂来负责DAO组件的生成。Spring实现了两种基本模式：单态模式和工厂模式。而使用Spring能够彻底避免使用工厂模式，由于Spring就是个功能很是强大的工厂。所以，彻底可让Spring充当DAO工厂。

由Spring充当DAO工厂时，无须程序员本身实现工厂模式，只须要将DAO组件配置在Spring容器中，由ApplicationContext负责管理DAO组件的建立便可。借助于Spring提供的依赖注入，其余组件甚至不用访问工厂，同样能够直接使用DAO实例。

优势：
Struts跟Tomcat、Turbine等诸多Apache项目同样，是开源软件，这是它的一大优势。使开发者能更深刻的了解其内部实现机制。
除此以外，Struts的优势主要集中体如今两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提升开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的经常使用标记外，不多开发本身的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是从此的一个发展方向，事实上，这样作，使系统的脉络更加清晰。经过一个配置文件，便可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤为是当另外一批开发者接手这个项目时，这种优点体现得更加明显。
缺点：
Taglib是Struts的一大优点，但对于初学者而言，却须要一个持续学习的过程，甚至还会打乱你网页编写的习惯，可是，当你习惯了它时，你会以为它真的很棒。
Struts将MVC的Controller一分为三，在得到结构更加清晰的同时，也增长了系统的复杂度。
Struts从产生到如今还不到半年，但已逐步愈来愈多运用于商业软件。虽然它如今还有很多缺点，但它是一种很是优秀的J2EE MVC实现方式，若是你的系统准备采用J2EE MVC架构，那么，不妨考虑一下Struts。

SSH2相比SSH1的不一样就是前者使用了更方便、更安全的MVC框架Struts2.。。

SSH2的主要内容包括：Struts二、Hibernate、Spring

Struts2是优秀的MVC框架。。。

Hibernate是如今最好用的ORM框架。。。

Spring是如今使用最广泛的Ioc容器。。。用来处理业务逻辑。

 

 

1.struts

struts框架具备组件的模块化，灵活性和重用性的优势，同时简化了基于MVC的web应用程序的开发。

优势：
Struts跟Tomcat、Turbine等诸多Apache项目同样，是开源软件，这是它的一大优势。使开发者能更深刻的了解其内部实现机制。
除此以外，Struts的优势主要集中体如今两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提升开发效率。另外，就目前国内的JSP开发者而言，除了使

用JSP自带的经常使用标记外，不多开发本身的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是从此的一个发展方向，事实上，这样作，使系统的脉络更加清晰。经过一个配置文件，便可把握整个系统各部分之间的联系，这对于后期的维护有着

莫大的好处。尤为是当另外一批开发者接手这个项目时，这种优点体现得更加明显。

另外，struts是业界"标准"（不少成功案例），学习资源丰富，HTML标签很是优秀

缺点：
Taglib是Struts的一大优点，但对于初学者而言，却须要一个持续学习的过程，甚至还会打乱你网页编写的习惯，可是，当你习惯了它时，你会以为它真的很棒。
Struts将MVC的Controller一分为三，在得到结构更加清晰的同时，也增长了系统的复杂度。
ActionForms使用不便、没法进行单元测试（StrutsTestCase只能用于集成）

【IT168技术文档】
Struts跟Tomcat、Turbine等诸多Apache项目同样，是开源软件，这是它的一大优势。使开发者能更深刻的了解其内部实现机制。 Struts开放源码框架的建立是为了使开发者

在构建基于Java Servlet和JavaServer Pages（JSP）技术的Web应用时更加容易。Struts框架为开放者提供了一个统一的标准框架，经过使用Struts做为基础，开发者可以更专一

于应用程序的商业逻辑。Struts框架自己是使用Java Servlet和JavaServer Pages技术的一种Model-View-Controller（MVC）实现.
具体来说,Struts的优势有:

1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现.

2. 有丰富的tag能够用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提升开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的经常使用标记外，不多开发

本身的标记，或许Struts是一个很好的起点。

3. 页面导航.页面导航将是从此的一个发展方向，事实上，这样作，使系统的脉络更加清晰。经过一个配置文件，便可把握整个系统各部分之间的联系，这对于后期的维护有

着莫大的好处。尤为是当另外一批开发者接手这个项目时，这种优点体现得更加明显。

4. 提供Exception处理机制 .

5. 数据库连接池管理

6. 支持I18N

缺点:
1、 转到展现层时，须要配置forward，每一次转到展现层，相信大多数都是直接转到jsp，而涉及到转向，须要配置forward，若是有十个展现层的jsp，须要配置十次struts

，并且还不包括有时候目录、文件变动，须要从新修改forward，注意，每次修改配置以后，要求从新部署整个项目，而tomcate这样的服务器，还必须从新启动服务器，若是业务

变动复杂频繁的系统，这样的操做简单不可想象。如今就是这样，几十上百我的同时在线使用咱们的系统，你们能够想象一下，个人烦恼有多大。

2、 Struts 的Action必需是thread－safe方式，它仅仅容许一个实例去处理全部的请求。因此action用到的全部的资源都必需统一同步，这个就引发了线程安全的问题。

3、 测试不方便. Struts的每一个Action都同Web层耦合在一块儿，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase能够实现它

的单元测试。

4、 类型的转换. Struts的FormBean把全部的数据都做为String类型，它可使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，并且转化的类型是不

可配置的。类型转化时的错误信息返回给用户也是很是困难的。

5、 对Servlet的依赖性过强. Struts处理Action时必须要依赖ServletRequest 和ServletResponse，全部它摆脱不了Servlet容器。

6、 前端表达式语言方面.Struts集成了JSTL，因此它主要使用JSTL的表达式语言来获取数据。但是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。

7、 对Action执行的控制困难. Struts建立一个Action，若是想控制它的执行顺序将会很是困难。甚至你要从新去写Servlet来实现你的这个功能需求。

8、 对Action 执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操做。

9、 对事件支持不够. 在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一个表单只能对应一个事件，struts这种事

件方式称为application event，application event和component event相比是一种粗粒度的事件。

Struts重要的表单对象ActionForm是一种对象，它表明了一种应用，这个对象中至少包含几个字段，这些字段是Jsp页面表单中的input字段，由于一个表单对应一个事件，所

以，当咱们须要将事件粒度细化到表单中这些字段时，也就是说，一个字段对应一个事件时，单纯使用Struts就不太可能，固然经过结合JavaScript也是能够转弯实现的。

2．Hibernate
Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了很是轻量级的对象封装，使得Java程序员能够为所欲为的使用对象编程思惟来操纵数据库。
Hibernate能够应用在任何使用JDBC的场合，既能够在Java的客户端程序实用，也能够在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate能够在应用EJB的J2EE架构中

取代CMP，完成数据持久化的重任。
大多数开发机构常常采起建立各自独立的数据持久层。一旦底层的数据结构发生改变，那么修改应用的其他部分使之适应这种改变的代价将是十分巨大的。Hibernate适时的填补了

这一空白，它为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架，功能却很是丰富。

优势：
a.Hibernate 使用 Java 反射机制 而不是字节码加强程序来实现透明性。
b.Hibernate 的性能很是好，由于它是个轻量级框架。 映射的灵活性很出色。
c.它支持各类关系数据库，从一对一到多对多的各类复杂关系。

缺点：它限制您所使用的对象模型。(例如，一个持久性类不能映射到多个表)其独有的界面和可怜的市场份额也让人不安，尽管如此，Hibernate 仍是以其强大的发展动力减轻了

这些风险。其余的开源持久性框架也有一些，不过都没有 Hibernate 这样有市场冲击力。

上面回贴情绪有点激动，但愿谅解，我不是由于有人批评Hibernate而感到不快，而是由于帖子里面的观点实在让我以为荒谬。无论以为Hibernate好也吧，很差也吧，我惟一以为

遗憾的是，在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread，跟了几百贴，其中包括Hibernate做者Gavin和LiDO JDO的

CTO，对于JDO和Hibernate有过一些激烈的争论，我曾经耐心的看了一遍，仍然没有发现针对Hibernate真正有力的攻击，那些所谓的攻击无非针对Hibernate没有一个GUI的配置工

具，没有商业公司支持，没有标准化等等这些站不住脚的理由。

补充几点个人意见：

1、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate能够用在任何JDBC可使用的场合，例如Java

应用程序的数据库访问代码，DAO接口的实现类，甚至能够是BMP里面的访问数据库的代码。从这个意义上来讲，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。

2、Hibernate是一个和JDBC密切关联的框架，因此Hibernate的兼容性和JDBC驱动，和数据库都有必定的关系，可是和使用它的Java程序，和App Server没有任何关系，也不存在

兼容性问题。

3、Hibernate不能用来直接和Entity Bean作对比，只有放在整个J2EE项目的框架中才能比较。而且即便是放在软件总体框架中来看，Hibernate也是作为JDBC的替代者出现的，而

不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：

传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提升上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。

2、运行效率：若是JDBC的代码写的很是优化，那么JDBC架构运行效率最高，可是实际项目中，这一点几乎作不到，这须要程序员很是精通JDBC，运用Batch语句，调整

PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的状况下采用结果集cache等等。而通常状况下程序员是作不到这一点的。所以Hibernate架构表现出最快的运行

效率。EB的架构效率会差的很远。

3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。可是在大的项目，特别是持久层关系映射很复杂的状况下，Hibernate效

率高的惊人，JDBC次之，而EB架构极可能会失败。

4、分布式，安全检查，集群，负载均衡的支持
因为有SB作为Facade，3个架构没有区别。

4、EB和Hibernate学习难度在哪里？

EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。因此难在你须要学习不少EJB设计模式来避开性能问题，须要学习App Server和EB的

配置来优化EB的运行效率。作EB的开发工做，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注自己就主要投入精力去考虑的对象持久层的设计上来。

Hibernate难在哪里？不在Hibernate自己的复杂，实际上Hibernate很是的简单，难在Hibernate太灵活了。

当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么能够选择的余地，因此你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑

选择哪一个方案，由于只有惟一的方案摆在你面前，你只能这么作，没得选择。

Hibernate相反，它太灵活了，相同的问题，你至少能够设计出十几种方案来解决，因此特别的犯难，究竟用这个，仍是用那个呢？这些方案之间到底有什么区别呢？他们的运行原

理有什么不一样？运行效率哪一个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性能够用Set，能够用List，还能够用Bag，到底哪一个效率高，你为难不为

难？查询能够用iterator，能够用list，哪一个好，有什么区别？你为难不为难？复合主键你能够直接在hbm里面配置，也能够自定义CustomerType，哪一种比较好些？你为难不为难？

对于一个表，你能够选择单一映射一个对象，也能够映射成父子对象，还能够映射成两个1:1的对象，在什么状况下用哪一种方案比较好，你为难不为难？

这个列表能够一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会以为幸福呢？仍是悲哀呢？若是你是一个负责的程序员，那么你必定会

仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会以为你已经陷入进去拔不出来了。若是是用EB，你第一秒种就已经作出了决定，根本没得选择，好比说集

合属性，你只能用Collection，若是是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。

3． Spring
它是一个开源的项目，并且目前很是活跃；它基于IoC（Inversion of Control，反向控制）和AOP的构架多层j2ee系统的框架，但它不强迫你必须在每一层 中必须使用Spring，因

为它模块化的很好，容许你根据本身的须要选择使用它的某一个模块；它实现了很优雅的MVC，对不一样的数据访问技术提供了统一的 接口，采用IoC使得能够很容易的实现bean的装

配，提供了简洁的AOP并据此实现Transcation Managment，等等
优势
a. Spring能有效地组织你的中间层对象，无论你是否选择使用了EJB。若是你仅仅使用了Struts或其余为J2EE的 API特制的framework，Spring致力于解决剩下的问题。
b. Spring能消除在许多工程中常见的对Singleton的过多使用。根据个人经验，这是一个很大的问题，它下降了系统的可测试性和面向对象的程度。
c. 经过一种在不一样应用程序和项目间一致的方法来处理配置文件，Spring能消除各类各样自定义格式的属性文件的须要。曾经对某个类要寻找的是哪一个魔法般的属性项或系统属

性感到不解，为此不得不去读Javadoc甚至源编码？有了Spring，你仅仅须要看看类的JavaBean属性。Inversion of Control的使用（在下面讨论）帮助完成了这种简化。
d. 经过把对接口编程而不是对类编程的代价几乎减小到没有，Spring可以促进养成好的编程习惯。
e. Spring被设计为让使用它建立的应用尽量少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。
f. 使用Spring构建的应用程序易于单元测试。
g. Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。
h. Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不经过EJB容器，若是

你仅仅须要与单个数据库打交道，甚至不须要一个JTA实现。
i. Spring为数据存取提供了一个一致的框架,不管是使用的是JDBC仍是O/R mapping产品（如Hibernate）。
Spring确实使你能经过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。

缺点：使用人数很少、jsp中要写不少代码、控制器过于灵活，缺乏一个公用控制器

 

 

ioc就是控制反转，能够理解为当spring被加载启动后，在spring配置的bean都会被这个框架预先实例化（做用于为单例），而后在你须要的这个对象的时候直接添加注入就能够调用这个对象了这样能够大大下降了类之间的耦合度。通常对于请求的对象咱们都要用scop域，会话以上的数据和对象直接用默认的单例就好了。aop就是事务管理，用的是面向切面的技术实现的（配置都是大同小异，网上随便找个改下就好了）。流程能够理解为你要给另外一我的打钱，因此业务上要分步操做，首先你要把你帐号的钱减掉，让后再对方的帐户添加，这是俩个步骤，对这个操做添加事务管理，就会监听这两个操做是否都完成，若是都完成就提交这个操做，若是有一个操做失败了，就恢复到以前的状态（即事