框架学习之框架的优缺点

Struts的优势有：

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

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

3. 页面导航.页面导航将是从此的一个发展方向，事实上，这样作，使系统的脉络更加清晰。经过一个配置文件，便可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤为是当另外一批开发者接手这个项目时，这种优点体现得更加明显。

4. 提供Exception处理机制 .

5. 数据库连接池管理

6. 支持I18N

缺点：

1、 转到展现层时，须要配置forward，每一次转到展现层，相信大多数都是直接转到jsp，而涉及到转向，须要配置forward，若是有十个展现层的jsp，须要配置十次struts，并且还不包括有时候目录、文件变动，须要从新修改forward，注意，每次修改配置以后，要求从新部署整个项目，而tomcat这样的服务器，还必须从新启动服务器，若是业务变动复杂频繁的系统，这样的操做简单不可想象。

2、 Struts 的Action必需是线程安全方式，它仅仅容许一个实例去处理全部的请求，因此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 这样有市场冲击力。

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产品

Spring确实使你能经过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。

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

Struts工做原理

　　MVC即Model-View-Controller的缩写，是一种经常使用的设计模式。MVC减弱了业务逻辑接口和数据接口之间的耦合，以及让视图层更富于变化。MVC的工做原理,以下图1所示：
    Struts 是MVC的一种实现，它将 Servlet和 JSP 标记（属于 J2EE 规范）用做实现的一部分。Struts继承了MVC的各项特性，并根据J2EE的特色，作了相应的变化与扩展。Struts的工做原理，

　　视图：主要由JSP生成页面完成视图，Struts提供丰富的JSP 标签库： Html，Bean，Logic，Template等，这有利于分开表现逻辑和程序逻辑。

　　控制：在Struts中，承担MVC中Controller角色的是一个Servlet，叫ActionServlet。ActionServlet是一个通用的控制组件。这个控制组件提供了处理全部发送到Struts的HTTP请求的入口点。它截取和分发这些请求到相应的动做类（这些动做类都是Action类的子类）。另外控制组件也负责用相应的请求参数填充 Action From（一般称之为FromBean）,并传给动做类（一般称之为ActionBean）。动做类实现核心商业逻辑，它能够访问java bean 或调用EJB。最后动做类把控制权传给后续的JSP 文件，后者生成视图。全部这些控制逻辑利用Struts-config.xml文件来配置。

　　模型：模型以一个或多个java bean的形式存在。这些bean分为三类：Action Form、Action、JavaBean or EJB。Action Form一般称之为FormBean，封装了来自于Client的用户请求信息，如表单信息。Action一般称之为ActionBean，获取从ActionSevlet传来的FormBean，取出FormBean中的相关信息，并作出相关的处理，通常是调用Java Bean或EJB等。

流程：在Struts中，用户的请求通常以*.do做为请求服务名，全部的*.do请求均被指向ActionSevlet，ActionSevlet根据Struts-config.xml中的配置信息，将用户请求封装成一个指定名称的FormBean，并将此FormBean传至指定名称的ActionBean，由ActionBean完成相应的业务操做，如文件操做，数据库操做等。每个*.do均有对应的FormBean名称和ActionBean名称，这些在Struts-config.xml中配置。

核心：Struts的核心是ActionSevlet，ActionSevlet的核心是Struts-config.xml。

Hibernate的主要接口：

核心接口 　　如下5个核心接口几乎在任何实际开发中都会用到。经过这些接口，你不只能够存储和得到持久对象，而且可以进行事务控制。 　　

Session接口 　　Session接口对于Hibernate 开发人员来讲是一个最重要的接口。然而在Hibernate中，实例化的Session是一个轻量级的类，建立和销毁它都不会占用不少资源。这在实际项目中确实很重要，由于在客户程序中，可能会不断地建立以及销毁Session对象，若是Session的开销太大，会给系统带来不良影响。　　

SessionFactory 接口 　这里用到了一个设计模式――工厂模式，用户程序从工厂类SessionFactory中取得Session的实例。令你感到奇怪的是SessionFactory并非轻量级的！实际上它的设计者的意图是让它能在整个应用中共享。典型地来讲，一个项目一般只须要一个SessionFactory就够了，可是当你的项目要操做多个数据库时，那你必须为每一个数据库指定一个SessionFactory。 SessionFactory在Hibernate中实际起到了一个缓冲区的做用，它缓冲了Hibernate自动生成的SQL语句和一些其它的映射数据，还缓冲了一些未来有可能重复利用的数据。 　　

Configuration 接口 　Configuration接口的做用是对Hibernate进行配置，以及对它进行启动。在Hibernate的启动过程当中，Configuration类的实例首先定位映射文档的位置，读取这些配置，而后建立一个SessionFactory对象。 　　　　

Query和Criteria接口  Query接口让你方便地对数据库及持久对象进行查询，它能够有两种表达方式：HQL语言或本地数据库的SQL语句。Query常常被用来绑定查询参数、限制查询记录数量，并最终执行查询操做。Criteria接口与Query接口很是相似，它容许你建立并执行面向对象的标准化查询,值得注意的是Query接口也是轻量级的，它不能在Session以外使用。 　　

Callback 接口 当一些有用的事件发生时――例如持久对象的载入、存储、删除时，Callback接口会通知Hibernate去接收一个通知消息。通常而言，Callback接口在用户程序中并非必须的，但你要在你的项目中建立审计日志时，你可能会用到它。如下是它的策略接口：

· 主键的生成 (IdentifierGenerator 接口) 　　

· 本地SQL语言支持 (Dialect 抽象类) 　　

· 缓冲机制 (Cache 和CacheProvider 接口) 　　

· JDBC 链接管理 (ConnectionProvider接口) 　　

.事务管理 (TransactionFactory, Transaction, 和 TransactionManagerLookup 接口) 　　

· ORM 策略 (ClassPersister 接口) 　　

· 属性访问策略 (PropertyAccessor 接口) 　　

· 代理对象的建立 (ProxyFactory接口) 　　

Hibernate为以上所列的机制分别建立了一个缺省的实现，所以若是你只是要加强它的某个策略的功能的话，只需简单地继承这个类就能够了，没有必要从头开始写代码。

Hibernate运行在两种环境下：可管理环境和不可管理环境 　　

· 可管理环境――这种环境可管理以下资源：池资源管理，诸如数据库链接池和还有事务管理、安全定义。一些典型的J2EE服务器（JBoss、Weblogic、WebSphere）已经实现了这些。 　　

· 不可管理环境――只是提供了一些基本的功能，诸如像Jetty或Tomcat这样的servlet容器环境。

传统的架构：
1) Session Bean <-> Entity Bean <-> DB

为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB

使用Hibernate来提升上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：
一、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构次之，EB的架构1最差。
二、运行效率：若是JDBC的代码写的很是优化，那么JDBC架构运行效率最高，可是实际项目中，这一点几乎作不到，这须要程序员很是精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的状况下采用结果集cache等等。而通常状况下程序员是作不到这一点的。所以Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。
三、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。可是在大的项目，特别是持久层关系映射很复杂的状况下，Hibernate效率高的惊人，JDBC次之，而EB架构极可能会失败。