MVC模式

MVC：

　　M(Model)：模型（表示应用程序核心，如数据这样的内部实体或者对数据加工这一动作）

　　V(View)：视图（显示数据，用于面向用户的外表模块）

　　C(Controller)：控制器（处理输入，表达外部和内部之间的关系）

一种框架模式，一种软件设计典范，目的是将业务逻辑、数据和界面显示分为三个方面来组织代码。

 

举个例子：

视图（View）：用户看到的并与之交互的界面，比如网页，视图就是我们平时所写的由HTML元素组成的页面，尽管现在有各种新的技术与视图相关，但视图终究的作用是作为一种输出数据并允许用户操纵的方式

模型（Model）：表示数据和业务规则的地方，一般分为数据模型和业务逻辑模型。数据模型：存放数据，比如账户的金额及用户的信息。业务逻辑模型：对数据的加工，比如转账这一动作中，对多个用户账户金额的处理。

控制器（Controller）：接受用户的输入并调用模型和视图去完成用户的需求，比如单击某个按钮发送表单时，控制器本身不输出任何东西和做任何处理，它只是接受请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

 

最典型的MVC就是JSP + Servlet + Javabean的模式：

JSP主要用于前台界面，servlet主要用于业务逻辑开发，Javabean用于获取参数，进行相应的处理。

因为JSP优点就是界面开发方便，但业务的处理不方便，servlet性能快，也较为安全，但就是不好显示给用户看，所以这一组合也就因为各自的优缺点而组合在一起了。

 

MVC：

优点

　　1.耦合性低

　　2.重用性高

　　3.生命周期成本低

　　4.部署快

　　5.可维护性高

　　6.有利软件工程化管理

缺点：

　　1.没有明确的定义

　　2.不适合小型，中等规模的应用程序

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

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

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

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

 

MVC并非某种具体的框架，或者说他并非属于具体的框架，它是一种模式，一种编程设计中的大体方向，它的目的就是对软件设计进行分工。

在自己初学编程的时候，那个时候不涉及这些编程上的各种思想，但是编久了自然就会想用某种想象来描述程序或者软件的样子。

一开始，软件的编写就是实现什么功能，要拿什么数据，给用户展现什么内容，全部一溜烟地写在寥寥几个函数方法里面，一大堆地就弄出来了，能做到实现功能，但是编写和修改就十分麻烦，或者根本完成不了。

之后自己想的解决方法，就是多写几个函数，要用到什么方法就调用这个函数，要做出修改，就直接找这个函数。这个动作对于自己来说就是主动解耦的方法，为了减少函数与函数之间的依赖性。

最后，学习了spring、struts、hibernate等几种框架之后，这个思维就有所变化了，将软件分成了好几个层次，数据层自然就是只做对数据的直接操作了；逻辑业务层就对数据操作这一操作之上进行加工，有判断，有循环，想要什么功能，就在其中做出条件的筛选来达成我的目的；对用户的页面层就专心写页面就行了；利用struts框架中特别的功能，我能从用户页面跳转到后台（这个过程是调用后台某个函数方法），并顺便传入几个数据，进行计算，怎么计算就靠后台这个函数方法去调用逻辑业务层的东西了，层层往下，返回的值又层层往上，获取到了数据又跳转到前台，呈现给用户了。

回过头再来看这一理解过程，MVC的思想就大体有些明白了，把整个软件程序分成了模型、视图、控制器这三个模块，各自完成各自的事情，也就有了如上MVC的优缺点。