MVC最佳实践

前一段日子,写了一篇《MVC就是一个选择题》,重点描述了我对MVC模式的迷惑。随着我对这个模式应用时间的深入,渐渐感到得心应手,这个模式早在30多年前就已经发明了,确实经受了时间的考验,可以说是千锤百炼。但是,实践过程中,我也发现,更多的时候照猫画虎还是有很多弊端的,想要真正做好MVC的选择题,必须在项目中不断犯错误,不断修正,才能逐渐走上正轨。我参加的项目主要运用了Yii框架,是目前比较流行的一个Web开发框架。随着前不久,1.1.6版本的发布,我发现Yii框架的文档中,多了一篇MVC最佳实践的文章。我想,这个文章对于初学者来说,应该具备相当的指导性,而且指导相当具体。如果也有跟我相同的迷茫,应该好好钻研一下这篇文章,并且身体力行去验证之,这里给出链接。我在这篇文章中,就是概括简述一下那篇文档的内容。

MVC的核心理念是代码的重用和关注点的分离(Separation of concern 我个人对这个理解就是将数据和表现进行分离)。如何正确遵循MVC的原理来编写代码是有一些基本指导原则可以遵循的。为了便于理解后面将要叙述的指导原则,我们这里认为一个典型的Web应用由以下几个子应用(部分)组成:

  • 前端——网站界面,面向普通用户
  • 后台——一部分有管理权限的用户用于维护Web应用的正常运转
  • 控制台——在终端中执行的命令,或者是定时任务如cronjob,用于日常运维
  • API——用于第三方合作,或者二次开发

Model

模型用于表示底层数据结构,经常在整个应用的不同部分共享,有些模型在前后台、API中都会用到,所以一个模型应该遵循的指导原则有:

  • 包含属性用于描述特定的数据
  • 应该包含业务逻辑,以确保数据能够满足表现的需要
  • 应该包含数据操作的代码,比如数据存储、检索
  • 不应该使用$_GET $_POST这样的只有在前端才会出现的数组,在控制台和API用到时候,可能就无法复用了
  • 不应该出现HTML代码,负责表现的代码应该放到view文件中

在上述指导原则下,可能会写出非常庞大的Model类(过多数据操作,业务逻辑代码包含其中)。这种情况下,建议进一步抽象,提炼出一个基类,包含最通用的功能,然后前端、后端和API在用到时候,将各个子应用才相关的逻辑放到基类继承出来的子类里面。

View

视图主要就用于前端表现的代码。

  • 包含HTML,以及所有负责表现的代码,可以出现PHP,但是只用于遍历数据、格式化数据
  • 不应该包含DB请求
  • 不应该出现引用$_GET $_POST这类数组的代码,这应该是Controller的工作。View只是专注于表现,布局等和页面呈现有关的业务,用户的请求数据应该由Controller和Model负责处理
  • 如果必要,可以访问Model和Controller的属性,不过这是为了满足表现的需要

可以使用诸如布局、部分视图、HTML Helper类、Widget等框架特性来最大程度重用View的代码。

Controller

控制器是将模型、视图和其他组件组装在一起形成一个应用的粘合剂。控制器直接负责处理终端用户的请求。

  • 可以访问$_GET $_POST这样的用户请求数组
  • 创建模型,并决定一个模型对象的生命周期
  • 不应该出现SQL语句,数据库请求应该放到Model中
  • 不应该出现HTML代码,而应该将其放入到View中

在一个设计良好的MVC应用中,控制器是非常轻量级的,经常只有几十行代码的样子;而Model总是非常复杂而且庞大,包含了所有的用于表现的数据及其操作方法。这是因为由数据结构和业务逻辑组成的模型对每个应用来说,都是独特的,需要大量的定制化工作来满足应用的需求;控制器的逻辑经常遵循一个特定的套路,在各个应用中都差不多,因此可以被框架底层代码极大程度地简化(也就是说不是控制器代码少,而是Web开发框架已经都抽象出来并且都帮你做好了,这也就是框架的价值和能够实现快速开发的原因)。