为什么选择SSM+Redis框架开发模式？

1.选择spring

　　目前企业的java应用中，spring框架是必须的，spring的核心是IOC（控制反转），它是一个大容器，方便组装和管理各类系统内外部资源，同时支持AOP（控制反转），这是对面向对象的补充（），目前广泛应用于日志和数据库事物控制，减少了大量重复代码，使得程序更为清晰，而且spring可以使模块解耦，控制对象之间的协作，所以spring框架是目前java最为流行的框架之一。

2.选择springMVC

　　SpringMVC和Struts2虽然都是MVC模式，都有着核心分发器等相同的功能组件，但：

1、Struts2是类级别的拦截， 一个类对应一个request上下文，SpringMVC是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应,所以说从架构本身上SpringMVC就容易实现restful url（）,而struts2的架构实现起来要费劲，因为Struts2中Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。

解释：什么是类级别拦截什么是方法级别拦截？

传递的参数的方式：struts2是靠action中的属性以及相应的get/set方法来传递请求数据的；springmvc是靠方法的形式参数来传递请求参数的。

其他文章里有说到：Struts2是类级别的拦截， 一个类对应一个request上下文，SpringMVC是方法级别的拦截，一个方法对应一个request上下文。这句话是什么意思呢？？？？

意思是说springmvc中一个controller中的业务方法是独立的，一个control可以写多个业务方法，通过@requestingmapping让一个请求对应一个方法，请求数据通过参数获取，彼此不相干扰。struts虽然也可以一个action中写多个方法，但是struts用的是action的属性来传递参数，所以一个action中的多个业务方法就可以共享这些属性数据了，就比较乱，所以通常我们会一个action类对应一个请求，。所以说：Struts2是类级别的拦截，SpringMVC是方法级别的拦截。

2、由上边原因，SpringMVC的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量，而Struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码 读程序时带来麻烦，每次来了请求就创建一个Action，一个Action对象对应一个request上下文。

解释：什么是request上下文？

actionContext（action上下文）的简单定义：

（1）ActionContext对象，非根对象，是Action运行的上下文，每个ActionContext是一个基本的容器，包含着Aciton运行需要的数据，比如请求参数，会话等。

（2）ActionContext也是线程安全的，每个线程都有一个独立的ActionContext，这样就不用担心值栈中值得线程安全问题了。

（3）获得ActionContext对象的方式：

第一种，使用ActionContext自身的方法来获取： ActionContext ctx =ActionContext.getContext();

第二种，使用ActionInvocation来获取：ActionContext ctx =actionInvocation.getInvocationContext();

（4）ActionContext里面存储着很多值：

a：Request的Parameters，请求中的参数，注意这里的数据是从数据对象中复制来的，因此这里的数据的变化是不会影响到请求对象里面的参数的值的。

b：Request的Attribute，请求中的属性，这里是一个Map，存放着请求对象的属性数据，这些数据和请求对象的Attribute是联动的。

c：Session的Attribute，会话中的助兴，这里是一个Map，存放着会话对象的属性数据，这些数据和会话对象的attribute是联动的。

d：Application的Attribute，应用的属性，这里是一个Map，存放着应用对象的属性数据，这些数据和应用对象的attribute是联动的。

e：attr，在所有的属性范围中获取值，依次搜索page, request, session 和applicaion

（5）ongl表达式取出action上下文中的值：

由于Struts2框架把OGNLContext设置为ActionContext，还把代表application、session、request这些对象的Map对象也放到ActionContext中去。

又因为ActionContext为非根对象，所以OGNL表达式访问ActionContext（action上下文）里面的application、session、request、attr对象中的值时，

需要加访问前缀#，以便告诉OGNL，寻值不是从根对象中，而是从action上下文的其他对象中寻找

3、由于Struts2需要针对每个request进行封装，把request，session等servlet生命周期的变量封装成一个一个Map，供给每个Action使用，并保证线程安全，所以在原则上，是比较耗费内存的。

4、 拦截器实现机制上，Struts2有以自己的interceptor机制，SpringMVC用的是独立的AOP方式，这样导致Struts2的配置文件量还是比SpringMVC大。

5、SpringMVC的入口是servlet，而Struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。

6、SpringMVC集成了Ajax，使用非常方便，只需一个注解@ResponseBody就可以实现，然后直接返回响应文本即可，而Struts2拦截器集成了Ajax，在Action中处理时一般必须安装插件或者自己写代码集成进去，使用起来也相对不方便。

7、SpringMVC验证支持JSR303，处理起来相对更加灵活方便，而Struts2验证比较繁琐，感觉太烦乱。

8、Spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高（当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果，但是需要xml配置的地方不少）。

9、 设计思想上，Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。

10、SpringMVC开发效率和性能高于Struts2。
11、SpringMVC可以认为已经100%零配置。

3.选择Mybatis

　　Hibernate做诶全映射框架，在需要存储过程（）或者复杂的sql时，全映射没有办法完全掌控数据库的sql,而优化sql是高并发（）、高响应系统的必然要求，而Mysql提供了动态sql、自动映射、接口编程等功能，所以它成为了最流行的java互联网持久层框架。

4.选择Redis

　　Nosql的成功在于，首先它是基于内存的，也就是数据放在内存中的，而不是像数据库那样把数据放在磁盘上，而内存的读取速度是磁盘读取速度的几十倍到上百倍，所以Nosql工具的速度远比数据库读取速度要快得多，满足了高响应的要求。数据库存储是经过结构化、多范式等有复杂规则的数据，还原为内存结构的速度较慢。Nosql在很大程度上满足了高并发、快速读写和响应要求，而redis已成为主要的Nosql工具。