框架优缺点（详细对比）

MyBatis

原理详解：

MyBatis 应用程序根据 XML 配置文件创建 SqlSessionFactory ， SqlSessionFactory 在根据配置，配

置来源于两个地方，一处是配置文件，一处是 Java 代码的注解，获取一个 SqlSession 。 SqlSession 包含

了执行 sql 所需要的所有方法，可以通过 SqlSession 实例直接运行映射的 sql 语句，完成对数据的增删改

查和事务提交等，用完之后关闭 SqlSession 。

优点：

1 、简单易学

mybatis 本身就很小且简单。没有任何第三方依赖，最简单安装只要两个 jar 文件 + 配置几个 sql 映射

文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

2 、灵活

mybatis 不会对应用程序或者数据库的现有设计强加任何影响。 sql 写在 xml 里，便于统一管理和优

化。通过 sql 基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。

3 、解除 sql 与程序代码的耦合

通过提供 DAL 层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测

试。 sql 和代码的分离，提高了可维护性。

4 、提供映射标签，支持对象与数据库的 orm 字段关系映射

5 、提供对象关系映射标签，支持对象关系组建维护

6 、提供 xml 标签，支持编写动态 sql 。

缺点：

1 、编写 SQL 语句时工作量很大，尤其是字段多、关联表多时，更是如此。

2 、 SQL 语句依赖于数据库，导致数据库移植性差，不能更换数据库。

3 、框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是

要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。

4 、二级缓存机制不佳

Mybatis与Hibernate对比

Mybatis 优势

MyBatis 可以进行更为细致的 SQL 优化，可以减少查询字段。

MyBatis 容易掌握，而 Hibernate 门槛较高。

Hibernate 优势

Hibernate 的 DAO 层开发比 MyBatis 简单， Mybatis 需要维护 SQL 和结果映射。

Hibernate 对对象的维护和缓存要比 MyBatis 好，对增删改查的对象的维护要方便。

Hibernate 数据库移植性很好， MyBatis 的数据库移植性不好，不同的数据库需要写不同 SQL 。

Hibernate 有更好的二级缓存机制，可以使用第三方缓存。 MyBatis 本身提供的缓存机制不佳。

spring mvc

优点

在 MVC 模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需要更改相应的层中的

代码而不会影响到其它层中的代码。

有利于开发中的分工，提高开发效率

在 MVC 模式中，由于按层把系统分开，那么就能更好的实现开发中的分工。网页设计人员可以进行开发

视图层中的 JSP ，对业务熟悉的开发人员可开发业务层，而其它开发人员可开发控制层。

组件重用，有利于代码复用，重用性高

分层后更有利于组件的重用。如控制层可独立成一个能用的组件，视图层也可做成通用的操作界面

缺点 不适合小型，中等规模的应用程序

费大量时间将 MVC 应用到规模并不是很大的应用程序通常会得不偿失。【这个是最明显的缺点，例如我

们仅仅需要到数据库查信息，如果不分层设计我们可以直接从视图型层到模型去访问，效率上会有所提

高，如果以代码的复杂性为代价，多了一层，代码量大大增加，在这个时候就降低了开发效率】

增加系统结构和实现的复杂性

对于简单的界面，严格遵循 MVC ，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多

的更新操作，降低运行效率

视图与控制器间的过于紧密的连接

视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之

亦然，这样就妨碍了他们的独立重用。【例如，不可能总是在 jsp 页面中直接访问模型，一般放在逻辑

控制层进行处理， servlet 】

视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的

频繁访问，也将损害操作性能。【例如，页面的有一部分数据我并没有更新，但是提交到模型层照样会

去获得返回显示 】

一般高级的界面工具或构造器不支持模式

改造这些工具以适应 MVC 需要和建立分离的部件的代价是很高的，会造成 MVC 使用的困难。

Struts2

我在项目开发过程中，一个具体的功能的开发流程是：拿到一个具体的功能需求文档和设计好的前台界

面（在开发中我不负责设计页面），分析需要从前台传递哪些参数，确定参数的变量名称，在 Action 中

设置相应的变量，这些参数在前台如何显示，并将页面上的一些控件适当使用 Struts2 提供的服务器端

控件来代替，编写 Action 对应的方法来完成业务逻辑，最后，做一些与配置文件相关的设置。当然实际

的开发比这个过程要复杂，涉及到数据库，验证，异常等处理。但是使用 Struts2 进行开发，你的关注

点绝大部分是在如何实现业务逻辑上，开发过程十分清晰明了。

优点

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

（ 2 ）丰富的标签库，大大提高了开发的效率。

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

（ 4 ）通过配置文件，就可以掌握整个系统各个部分之间的关系。

（ 5 ）异常处理机制，只需在配置文件中配置异常的映射，即可对异常做相应的处理。

缺点

(1)Struts2 中 Action 中取得从 jsp 中传过来的参数时还是有点麻烦

(2) 校验还是感觉比较繁琐，感觉太烦乱，也太细化了，如果校验出错的只能给用户提示一些信息

(3) 安全性有待提高。

Spring MVC和Struts2的比较的优点

我们用 struts2 时采用的传统的配置文件的方式，并没有使用传说中的 0 配置。 spring3 mvc 可以认为已

经 100% 零配置了（除了配置 spring mvc-servlet.xml 外）。

Spring MVC和Struts2的区别：

机制： spring mvc 的入口是 servlet ，而 struts2 是 filter （这里要指出， filter 和 servlet 是不同的。以前认

为 filter 是 servlet 的一种特殊），这样就导致了二者的机制不同，这里就牵涉到 servlet 和 filter 的区别

了。

性能： spring 会稍微比 struts 快。 spring mvc 是基于方法的设计，而 sturts 是基于类，每次发一次请求

都会实例一个 action ，每个 action 都会被注入属性，而 spring 基于方法，粒度更细，但要小心把握像在

servlet 控制数据一样。 spring3 mvc 是方法级别的拦截，拦截到方法后根据参数上的注解，把 request

数据注入进去，在 spring3 mvc 中，一个方法对应一个 request 上下文。而 struts2 框架是类级别的拦

截，每次来了请求就创建一个 Action ，然后调用 setter getter 方法把 request 中的数据注入； struts2 实

际上是通过 setter getter 方法与 request 打交道的； struts2 中，一个 Action 对象对应一个 request 上下

文。 参数传递： struts 是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。

设计思想上： struts 更加符合 oop 的编程思想， spring 就比较谨慎，在 servlet 上扩展。

intercepter 的实现机制： struts 有以自己的 interceptor 机制， spring mvc 用的是独立的 AOP 方式。这样

导致 struts 的配置文件量还是比 spring mvc 大，虽然 struts 的配置能继承，所以我觉得论使用上来讲，

spring mvc 使用更加简洁，开发效率 Spring MVC 确实比 struts2 高。 spring mvc 是方法级别的拦截，一

个方法对应一个 request 上下文，而方法同时又跟一个 url 对应，所以说从架构本身上 spring3 mvc 就容

易实现 restful url 。 struts2 是类级别的拦截，一个类对应一个 request 上下文；实现 restful url 要费劲，

因为 struts2 action 的一个方法可以对应一个 url ；而其类属性却被所有方法共享，这也就无法用注解或

其他方式标识其所属方法了。 spring3 mvc 的方法之间基本上独立的，独享 request response 数据，请

求数据通过参数获取，处理结果通过 ModelMap 交回给框架方法之间不共享变量，而 struts2 搞的就比较

乱，虽然方法之间也是独立的，但其所有 Action 变量是共享的，这不会影响程序运行，却给我们编码，

读程序时带来麻烦。

另外， spring3 mvc 的验证也是一个亮点，支持 JSR303 ，处理 ajax 的请求更是方便，只需一个注解

@ResponseBody

Spring

Spring 是一个轻量级的 DI 和 AOP 容器框架。

说它轻量级有一大部分原因是相对与 EJB 的（虽然本人从没有接触过 EJB 的应用），重要的是， Spring 是

非侵入式的 ( 所谓非侵入式就是远程调试 而不植入， spring 不再用 new 的方式来创建对象，而是使用依

赖注入的方式 ) ，基于 spring 开发的应用一般不依赖于 spring 的类。

DI: 称作依赖注入 (Dependency Injection), 和控制反转一个概念，具体的讲，当一个角色需要另外一个角

色协助的时候，在传统的程序设计中，通常有调用者来创建被调用者的实例。但是在 spring 中创建被调

用者将不再有调用者完成，因此叫控制反转。创建被调用对象有 Spring 来完成，在容器实例化对象的时

候主动的将被调用者（或者说它的依赖对象）注入给调用对象，因此又叫依赖注入。

AOP ： Spring 对面向切面编程提供了强有力的支持，通过它让我们将业务逻辑从应用服务（如事务管

理）中分离出来，实现了高内聚开发 ( 所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责

一项任务，也就是常说的单一责任原则。 ) ，应用对象只关注业务逻辑，不再负责其它系统问题（如日

志、事务等）。 Spring 支持用户自定义切面。

面向切面编程是面向对象编程的有力补充。面向对象编程将程序分成各个层次的对象，面向切面的程序

将运行过程分解成各个切面。 AOP 是从运行程序的角度去考虑程序的结构，提取业务处理过程的切面，

OOP 是静态的抽象， AOP 是动态的抽象，是对应用执行过程的步骤进行抽象，从而获得步骤之间的逻辑

划分。

容器： Spring 是个容器，因为它包含并且管理应用对象的生命周期和配置。如对象的创建、销毁、回调

等。

框架： Spring 作为一个框架，提供了一些基础功能，（如事务管理，持久层集成等），使开发人员更专

注于开发应用逻辑。

优点

1. 提供了一种管理对象的方法，可以把中间层对象有效地组织起来。一个完美的框架 “ 黏合剂 ” 。

2. 采用了分层结构，可以增量引入到项目中。

3. 有利于面向接口编程习惯的养成。

4. 目的之一是为了写出易于测试的代码。

5. 非侵入性，应用程序对 Spring API 的依赖可以减至最小限度。

6. 一致的数据访问介面。

7. 一个轻量级的架构解决方案。

缺点

1.jsp 中要写很多代码、控制器过于灵活，缺少一个公用控制器

2.Spring 不支持分布式，这也是 EJB 仍然在用的原因之一。