MVC 框架学习笔记

  • 一、MVC 介绍
  • 二、MVC 目的
  • 三、MVC 内容
  • 1. 控制器 - Controller
  • 2. 视图 - View
  • 3. 模型 - Model
  • 四、MVC 的误解


一、MVC 介绍

MVCModel-View-Controller 的缩写,表示模型-视图-控制器的软件设计模式,最早由 Xerox PARC 在二十世纪八十年代为编程语言 Smalltalk 发明的一种软件设计模式。

MVC 被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

二、MVC 目的

MVC 的目的是实现一种动态的程序设计,通过一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,便于后续对程序的修改和扩展简化,并且使程序某一部分的重复利用成为可能,达到在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。

三、MVC 内容

使用 MVC 应用程序被分成三个核心部件:模型、视图、控制器。

  • 控制器(Controller):截获用户请求,管理数据通信与派发。
  • 模型(Model):数据获取及业务逻辑。
  • 视图(View):渲染数据与用户界面。

注意:从依赖关系看,模型不依赖视图和控制器,而视图和控制器依赖模型。

与其它设计模式不同,MVC 模式并没有直接反映一个能够编写或配置的类结构。相反,MVC 更像一个概念上的指导原则或范型。概念上的 MVC 模式被描述为三个对象(模型、视图和控制器)之间的关系。任何输入都通过控制器进入系统,然后由控制器选择模型进行处理,处理结果由视图展示。

mvc架构顺序图 简单介绍mvc框架_数据

1. 控制器 - Controller

控制器主要是接收用户请求并响应用户,调用模型处理,将结果交给视图展示。

控制器本身并没有对获取的数据进行操作与预处理,也没有输出任何数据,只是根据用户的输入与需求(大多数情况由视图传递用户的请求),判断需要调用的模型,告知模型需要获取的数据或发生变化的数据,由模型对数据进行处理。最后,由控制器响应用户,将数据传递给对象,由对象对结果进行展示。

控制器是视图获知模型数据变化及传递数据变化需求的管道。

2. 视图 - View

视图的职责比较明确,负责渲染数据、 UI 界面,以及获知用户请求并传达给控制器。

视图需要正确的显示数据,然而本身并不负责存储所展示的数据进行存储(也不意味着视图决不存储数据),所以视图需要感知模型数据的变化。因其所展示的数据都来自控制器,并且能够将用户请求和对数据的变更传递给控制器,可知视图与模型之前没有进行直接通信,视图与模型的通信都是以控制器为中介。

3. 模型 - Model

模型封装了应用数据、应用流程和业务逻辑。

模型是 MVC 中逻辑最复杂,几乎应用的所有业务逻辑都需要在这里处理。模型封装了特定的应用数据,并且定义操作和处理该数据的逻辑和计算。模型返回的数据需要保持中立,即模型的数据应该与数据格式无关,一个模型的数据能够供多个视图使用,但是模型应该与视图没有直接的连接,模型不会受视图的影响。实际的应用中模型可能会分为数据访问层(DAO)和服务层(Service)。

四、MVC 的误解

MVC 已经成为我们最常误用的模式,现在大部分流行的框架中都借鉴了 Ruby on RailsActiveRecord(AR) 概念,数据库中的每一个 Table 都可以用 AR 类来方便地进行增删改查操作,把 AR 当做 Model ,并推荐放在一个名为 Model 的目录下。

于是,许多人在根据表设置对应的 AR 类后,便想当然的认为已经拥有 Model 层了,但其实 AR 只是 DAO(数据访问层),并不是 Model 层。

对 Model 的错误理解,

  • 一些人会将所有的业务逻辑都放在了 Controller 中,造成 Controller 的臃肿,如果需要对项目进行修改和扩展,或者开发 API 接口,这种写法代码基本无法复用,许多功能都需要重写。
  • 还有的人可能了解的一些框架推荐的概念:瘦控制器,胖模型。有这个概念的人倒不会出现臃肿的 Controller ,但是因为对 Model 的错误认识,可能将业务逻辑写在了 AR 中。

实际上将领域相关业务放在 AR 中,叫做“纯粹的领域模型”,纯粹的领域模型在小型应用中或许看不出问题,但是在大系统中,却是要将业务抽象出来,封装各个领域的业务逻辑,能够具有强大的可维护性和可移植性,避免 Model 过于臃肿,遵循重要的面向对象设计原则:接口隔离。

所以,需要设立一个独立的业务 Model 层,即所谓的 Service 。AR ,所谓的 DAO ,实现存取逻辑、数据层次的缓存、数据切分等等功能。Service 实现逻辑、业务层次的缓存、领域对象的合并处理等等。拥有了 Service 后,即使业务需求变更,只需要修改 Service 即可,甚至重设 Facade Service 。

参考资料

  1. MVC 框架 百度百科
  2. MVC架构的职责划分原则
  3. 什么是 MVC 的领域模型
  4. Cocoa Core Competencies Apple 开发文档