可以对 SSI 说，我叫 SI ！
太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
Structs + Spring + MyBatis
Spring MVC + Spring + MyBatis
第一部分，都是请求分发；
1、Structs 靠 XML 配置来正确找到请求匹配的 Servlet 去执行，同时有或多或少的要求；
2、Spring MVC 靠注解，去指定包路径下，搜类文件？还是怎么个搜法，反正通过类前的 @Controller 以及其方法前的注解，匹配到对应的方法来执行，这种方式只需要方法和类前有注解，耦合低得基本可以不考虑，这算不算 Structs 1 到 Structs 2 飞跃 后的，又一次飞跃呢？事实上， Structs 2 已经不是 Structs 了，而是 webWorks 的升级。
第二部分，实际上 Spring 并没有参与实际的运行流转，只不过是当了把小工，在人家要用东西之前，就给准备好备用而已；这在当今内存足够大的情况下，无可厚非，以空间换时间，换得起；反过来讲，如果空间不足的时侯，这些弄一堆东西放那儿，确实影响性能，Anroid 上的 Spring 框架还没细研究过，不知道有什么新奇招数，别再因为它，现如今的 2G 内存的 Android 手机已经不再卡的状况，又被扭转了，也许是逼着 3G 内存时代的到来吧！
第三部分、Mybatis 前身叫 iBatis ，这次细看了映射的风格，自然多了，简单多了，难怪要重启个名字，要步入大堂了嘛。从栩置好的 SQL 到 Java 的接口方法实现动态注入，确实先进，而其本身还可以依托 Spring 再进一步注入，我了个去，完全不用管那些锁碎的事情了，走到门前，门自动开了，就端好奶茶送给客人品尝足矣。
实际使用发现，你还真不能把 Spring MVC 和 Spring 配到一起去，那样工作不了。因为 Spring MVC 自已内部维护着一份 Spring 的控制反转容器，所以这个 Spring MVC 即可以理解为，是Spring 出品的 MVC 框架，又可以理解为 这个MVC 框架里面已经内置 Spring 的依赖注入了，即有里儿，又有面儿，那么可以改写成：
Spring MVC + MyBatis 框架组合了，简称 SM ？或者 SI ？要么 SB ？随意吧
后附觉得重要的两篇官方文档：
http://mybatis.github.io/mybatis-3/zh/configuration.html#mappers
http://mybatis.github.io/spring/zh/getting-started.html
没有超链接，复制、粘贴一下，显得更重要吧。
这两篇文档说得不是一个事儿哟，不是同一文档的不同版本。
