MVC 架构模式

面试的时候被问到有关 MVC 的问题，虽然这块知识点并不难，但还是总结一下，下次再遇到的话，争取能做到侃侃而谈，而不是简简单单把概念给复述一遍。

什么是 MVC？

MVC 模型代表 Model - View - Controller，即模型 - 视图 - 控制器模式，从上到下依次介绍：

• View（视图）

  简单来说，就是负责数据的可视化。

• Controller（控制器）

  通常控制器用来从视图读取数据，并发送给对应的模型处理，再将结果反馈给视图显示。充当视图与模型之间数据交互的桥梁。

• Model（模型）

  模型是用于处理应用程序中业务数据和逻辑的部分，负责直接与数据库打交道。

为什么使用 MVC？

MVC 属于架构模式的一种，所谓架构就是如何设计一个程序的结构。MVC 将程序结构划分为三层，每一层都对外提供了可供上层调用的接口，既能维系三层之间的联系，也能保持相对的独立性。

而每一层都有各自的职责，我们可以将同一逻辑的代码聚集到一个组件，再放到对应的层次中。视图层作个性化的定制页面，而无需知晓下层业务的具体实现。同样的，控制层专心协调视图与模型的数据交互，模型层处理业务逻辑，无需关心数据该如何显示。

这种将业务逻辑、数据和界面分离的代码组织形式，降低了模块间的耦合度，有利于日后的维护与扩展。

MVC 的理解误区

先说控制层，为什么要把控制层单独拎出来说呢？因为很多人都误解了 MVC 的真正含义，他们只是把简单地把程序划分为三层设计，并没有理解到 MVC 的内涵。

前面已经说了，控制层只是负载协调视图层与模型层的数据交互，就像一个粘合剂，把视图层和模型层联系起来，除此之外再无其他。而有的程序员却喜欢在控制层写大量的业务处理代码，这是十分不合适的。

如果这样做了，那 MVC 的优势不就被你自己亲手扼杀了吗？MVC 的核心思想是 Controller 可以自由调用 Model，Model 之间的互相调用亦是如此，这是 MVC 的精髓所在。而 Controller 之间是不可以互相调用的，试问此时你要如何复用 Controller 中的业务代码呢？

所以说各司其职很重要，不要胡乱指派任务，否则就是在给自己挖坑。

另外，很多人都知道 Controller - Service - Dao 三层架构，其中 Controller 和 Service 我们可以认为就是 MVC 中的控制层和模型层。而 Dao 其实不属于 MVC，Dao 封装了访问数据访问的代码，Service 则去调用 Dao 提供的接口来处理数据，仅此而已。

MVC 的优点

• 耦合性低

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

• 重用性高

  一个模型能被多个视图共享，这意味着从模型传回来的数据能以多种方式显示，而不需要为每一种显示方式编写特定的代码，大大减少了代码量。

• 部署快

  使用 MVC 模式使开发时间得到相当大的缩减，后台程序员集中精力于业务逻辑，前端程序员集中精力于表现形式上。

• 可维护性高

  分离视图层和业务逻辑层也使得 WEB 应用更易于维护和修改。

• 有利软件工程化管理

  由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。

MVC 的缺点

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

  对于简单的界面，严格遵循 MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。所以说 MVC 不适合用于小型、中型应用程序。

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

  视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

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

  依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。