一，首先是一个MVC框架。
在web模型中，MVC是一种很流行的框架，通过把Model，View，Controller分离，把较为复杂的web应用分成逻辑清晰的几部分，是为了简化开发，减少出错。还是为了组内开发人员之间的配合。总之就是一种分层工作的办法。
二，springMVC，是spring的一个子框架，当然拥有spring的特性，如依赖注入。
三，springMVC的信息流是什么样的？
首先用户通过HTTP请求到服务器，服务器会根据你的url来将请求转到不同的控制器Controller。这是第一步，具体需要做的是在web.xml中设置URLpattern映射到spring的DispatcherServlet，这是控制器是负责第一道处理，用来转发请求的，它会将请求转发到合适的Controller上。那么问题来了，它是根据什么转发呢？这个问题有些混乱，原因是springMVC一直在升级，不断贡献新的url到Controller的映射方法。但是万变不离其宗，不管如何变，它的目的都不变，就是设法建立url到Controller的映射，找到这个目的之后，看起来就容易一些。具体来看，
方法1，在springmvc的配置文件中，直接将bean的name写成一个url，如
<bean name=”/product_input” class="com.ap.ProductInputController" />
通过这句配置，就直接将/product_input这url的请求转发到了ProductInputController这个类上。
注：但是这个方法被认为是老套的方法，现在已经不流行了。了解就可以，现在推荐的是注解的方式，即方法2的方式。
方法2，这种方式，在给Controller命名时，就可以无所谓了， 它的映射不是依赖这个名字，所以可以像下面这种方式来写这个bean的配置，可以随便起一个，如
<bean name=”product” class="com".ap.ProductInputController />
到这里，显然还是没有实现url到Controller的映射，因为url都还没看见呢，
现在的springMVC有一个注解是RequestMapping，专门负责映射url的，比方说需要映射到ProductInputController的 addProduct()这个方法，只需要在这个方法上加上一个注解，如
@RequestMapping(name=”product_input”)
addProduct()
通过这个注解，就可以将product_input这个url映射到addProduct这个方法了。是不是很简单。其实做的事情都一样，只不过是换了一种写法和位置。
感觉好神奇的样子，我一开始也有这种感觉，直到我了解了原始Servlet是如何将url和处理业务的类联系起来的，才发现这个过程也没有那么神秘，这里推荐一本书《SpringMVC学习指南》 Paul Deck著，适合0基础的人看，例子很详细。
我大概说一下url到Controller是怎么回事：
起点是，用户通过HTTP请求了服务器，那么一定就有URL，比方说是http://www.dudu.com/getName，其中getName就是我的url，假设你的servlet是部署在tomcat中的，在web.xml这个配置文件中，应该有url到某个类的关系，或者通过别的注解的方法 如@Webservlet(name= “xxController”, urlPatterns = {“product_input”}), 这里意思就是这个url进来后，把请求交给xxController这个class去处理，这个类继承了HttpServlet, 并且重写的doGet方法，你的请求就会来到这个方法里，然后，在方法内调用request.getRequestURI这个方法，拿到了你的url=getName，之后就是字符串匹配equals，调用后面具体的类。
我们使用框架的原因，就是在开发中，这样的步骤都是重复的，而且每次都一样，所以写框架的人，就把这样套路式的代码封装了， 细节都交给他来处理，我们只要做两件和自己业务相关的事，一个是确定url，二是，这个url指向那个类。写到这里基本把url到Controller这件事说完了。这里有两个类一个是DispatcherServlet，这个是SpringMVC框架自带的，一个就是你自己处理业务的类，比如是ProductController。控制器的命名都喜欢叫XXXController。下面画一张图说明这一步
四，MVC，先说的居然是C，Controller，下面说View，就是视图，展示。用户的浏览器，看到的都是比较美观的网页，这就是HTML，它负责来将苦涩的数据，展现成各种样式，让普通用户看起来也不错，而不是一堆JSON数据。用户的请求进来之后，肯定还是要返回给用户页面的，这每个页面就是一个VIEW，view就像一个网页的框架，某个页面的框架是固定的，不同的是其中的数据。比方说购物车页面，就是一个框架。那你的购物车和我的大体看起来是一样的，但其中的具体内容不同，因为买的商品不同，而这具体的东西，或叫做数据，就是Model。现在M和V就有了。
下面再串一个这个流程，刚才说到请求已经到了Controller，这个类的作用就是1，选择适当的view返回给用户，2，组织数据，即生成Model。网络传输和信息技术主要处理的就是数据，而现在数据就放在Model中，或者把放数据的地方叫做Model，比如用户在请求查询用户信息，那么Controller做的就是，在数据库中找到这些信息，然后把信息添加到Model中，然后把Model和对应的View一起返回给DispatcherServlet。 这里继续补充上一张图：
五，现在DispatcherServlet已经拿到Model里的数据和该用哪个View来展示给用户了。
所以会将Model和View融合，具体就是用Model的数据把View的变量都换成具体的值，然后view就变成一个HTML的页面了，最后把这个HTML返回给用户，用户那边用浏览器来解释HTML，看到就是正常的网页。 全过程结束。
