MVC模式的正确理解

前言：MVC模式用于应用程序的分层开发，MVC要实现的目标是将数据、业务逻辑和软件用户界面分离以提高代码的可扩展性和可维护性。。

一、MVC模式的简介

1、MVC模式的概念

MVC模式的全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，是一种软件设计典范。它是用一种业务逻辑、数据与界面显示分离的方法来组织代码，将众多的业务逻辑聚集到一个部件里面，在需要改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑，达到减少编码的时间。

View层是界面，Model层是业务逻辑和数据，Controller层用来调度View层和Model层，将数据、业务逻辑和用户界面合理的组织在一起，起粘合剂的效果。所以Controller中的内容能少则少，这样才能提供最大的灵活性。

2、MVC模式的历史发展

a、在桌面程序中

MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器。

使用的MVC的目的：在于将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如Windows系统资源管理器文件夹内容的显示方式，下面两张图中左边为详细信息显示方式，右边为中等图标显示方式，文件的内容并没有改变，改变的是显示的方式。不管用户使用何种类型的显示方式，文件的内容并没有改变，达到M和V分离的目的。

b、在网页当中

V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操纵的方式。

M即model模型是指模型表示业务规则和数据。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

MVC举例：

最典型的MVC就是jsp+servlet+javabean模式。

JavaBean作为模型(Model)，既可以作为数据模型来封装业务数据，又可以作为业务逻辑模型来包含应用的业务操作。其中，数据模型用来存储或传递业务数据，而业务逻辑模型接收到控制器传过来的模型更新请求后，执行特定的业务逻辑处理，然后返回相应的执行结果。

JSP作为表现层(View)，负责提供页面为用户展示数据，提供相应的表单（Form）来用于用户的请求，并在适当的时候（点击按钮）向控制器发出请求来请求模型进行更新。

Serlvet作为控制器(Controller)，用来接收用户提交的请求，然后获取请求中的数据，将之转换为业务模型需要的数据模型，然后调用业务模型相应的业务方法进行更新，同时根据业务执行结果来选择要返回的视图。

二、MVC模式总结

1、MVC要实现的目标是将数据、业务逻辑和软件用户界面分离以以使代码可扩展性、可复用性、可维护性、灵活性加强。

View层是界面，Model层是业务逻辑和数据，Controller层用来调度View层和Model层，将数据、业务逻辑和用户界面合理的组织在一起，起粘合剂的效果。所以Controller中的内容能少则少，这样才能提供最大的灵活性。

比方说，有一个View会提交数据给Model进行处理以实现具体的行为，View通常不会直接提交数据给Model，它会先把数据提交给Controller，然后Controller再将数据转发给Model。假如此时程序业务逻辑的处理方式有变化，那么只需要在Controller中将原来的Model换成新实现的Model就可以了，控制器的作用就是这么简单， 用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。

2、合理的使用MVC有很多好处，要一一道尽是一件异常困难的任务。在这里我们通过一个反面示例来侧面的证明正确使用MVC的好处与依据。很多程序员偏爱于将业务逻辑放在Controller中，我极力反对这种做法，现在我就来证明这中做法的错误性。

我们知道在写程序时，业务逻辑的重复使用是经常要面对的场景。 如果业务逻辑写在控制器中， 要重用它的唯一方法就是将它提升到父类之中，通过继承来达到代码复用的效果。但这么做会带来一个巨大的副作用，违背了一项重要的面向对象设计原则：接口隔离。

什么是接口隔离，我在这里简单的讲述一下。通俗一点讲，接口隔离就是当一个类需要继承另一个类时， 如果被继承的类中有继承的类用不到的方法或者属性时，就不要去实现这个继承。如果真的情非得已必须要继承，那么也需要从被继承的类中再提取出一个只包含需要部分功能的新类型，最终去继承这个新类型才是正确的做法。 换句话说，实现继承的时候，不要去继承那些用不到的事物。

回到之前的话题，通过继承父控制器的方式复用业务逻辑时，往往会出现为了重用一个方法而继承来一大堆用不到的方法，表面上看起来似乎没什么问题，但是这会使代码变的难以理解，长此以往， 软件的代码会朝着不健康的方向发展。

要知道，使用继承的条件是很苛刻的，我们学习面向对象变编程继承特性时，第一课就是只有满足IS-A（是一个）关系时才可以使用继承，如果仅仅是复用代码，并不是我们使用继承的理由。使用组合是复用代码提倡的方式，也就是所谓的HAS-A（有一个）的关系，相信每个程序员都听过“少用继承，多有组合”这句话，这句话是软件开发业的先驱们千锤百炼总结出来的，值得我们去遵循。

各Model之间是可以相互调用的， Controller也可以无障碍的调用Model，因此将业务逻辑放在Model中可以灵活的使用组合的方式复用代码。

而Controller之间是不可以相互调用的，要复用代码只能将代码提升至父类，通过继承实现，显然这种做法既不正确，也不灵活，因此完全不提倡。

综上所述，仅仅只是代码复用这一点，也足以将“厚Controller，薄Model”这种不健康的MVC思想打入十八层地狱。

三、MVC框架的优点

1、耦合性低

视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

2、代码重用性高

MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。

3、部署快，生命周期成本低

MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上

4、有利软件工程化管理

由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户

四、Spring MVC 的架构

为解决持久层中一直未处理好的数据库事务的编程，又为了迎合 NoSQL 的强势崛起，Spring MVC 给出了方案：

传统的模型层被拆分为了业务层(Service)和数据访问层（DAO,Data Access Object）。 在 Service 下可以通过 Spring 的声明式事务操作数据访问层，而在业务层上还允许我们访问 NoSQL ，这样就能够满足异军突起的 NoSQL 的使用了，它可以大大提高互联网系统的性能。

特点：

1. 结构松散，几乎可以在 Spring MVC 中使用各类视图

2. 松耦合，各个模块分离

3. 与 Spring 无缝集成

 

参考链接：深入理解MVC模式