感觉刚学会MVC-老生再谈一谈

前言:

上学这么多年,总结出来一条道理,越是觉得自己会的东西,当有一天忽然不懂了然后再弄懂,一定是又收获了。

本文为博主在网上阅读的一篇文章,对MVC有了深层次的理解,故整理如下。


很多的程序猿与程序媛 把model该干的事情放到了Controller甚至是View,

不能说不对,因为毕竟程序也可以运行,代码的复用性与可维护性很差。还是多规范一点比较好嘛。

简而言之:

Controller:桥梁,控制调度作用,调用哪个model logic,给哪个view , 不要有过多的业务处理

View: 直观展示,用户交互界面

Model: 数据(data) , 业务(logic)支持者【项目复杂,关键的地方】


看了上边,你平常是这样写代码的吗?文章挺长的,但建议好好读一下吧,关键内容已经标红。

( 原文:http://www.digpage.com/mvc.html  )

一.MVC
MVC是一种设计模式(Design pattern),也就是一种解决问题的方法和思路
是上世纪80年代提出的,到现在已经颇有历史了。
MVC的意义在于指导开发者将数据与表现解耦,提高代码,特别是模型部分代码的复用性

MVC不仅仅存在于Web设计中,在桌面程序开发中也是一种常见的方法。MVC的出现已经有一段历史了。 记得我最早了解到MVC的时候,是在Microsoft的Visual C++ 中的MFC中。 当时年少无知,以为是MFC中特有的东西。后来随之不断学习,才发现自己的天真。 所以说,学得越多,就越觉得自己无知。越觉得自己无知,就越懂得敬畏和谦逊。 从这个角度讲,同学们,最好不要看不起谦逊的人。
有个这么一个段子,说一天A君在圈内聚会时,朋友介绍了另一个人B君互相认识。 聚会场合嘛,这很正常,也很普遍。于是AB君小聊了一下。按国人的习惯,A君就问了“先生在哪高就?”。 B君只说了句,“谈不上高就,炒炒股。” “哦,原来是炒股的。”A君心想,虽没觉得什么不对,但心理觉得B有点low,只是没说破,也没表现出来。 过后了一段时间,一次偶然机会,发现原来B君是国内某上市公司的二股东,身家过亿。 人家没说慌,确实是炒股的……
话说远了,我们还说正题。MVC是三个单词的缩写:Model, View, Controller。 MVC是一种设计模式,目前几乎所有的Web开发框架都建立在MVC模式之上。 当然,最近几年也出现了一些诸如MVP, MVVM之类的新的设计模式。 但从技术的成熟程度和使用的广泛程度来讲,MVC仍是主流。
Yii是一个Web框架,从Web开发的分工来讲,Yii的开发工作中,承担后端的内容多一些,毕竟主要就是PHP开发。 前端主要是在HTML、JavaScript、CSS上进行开发,然后通过Yii把前端的内容管起来,如通过Assets等。 这一章要讲的MVC,主要是针对后端的。 前端的MVC严格来讲不属于Yii的范畴,这里我们就不作过多介绍。 如果想了解前端的MVC,可以看看Backbone.js Angular.js等前端框架。

二.MVC的三要素
MVC是模型(Model)、视图(View)、控制器(Controller)3个单词的缩写。 下面我们从这3个方面来讲解MVC中的三个要素。
  • Model是指数据模型,是对客观事物的抽象。 如一篇博客文章,我们可能会以一个Post类来表示,那么,这个Post类就是数据对象。 同时,博客文章还有一些业务逻辑,如发布、回收、评论等,这一般表现为类的方法,这也是model的内容和范畴。 对于Model,主要是数据、业务逻辑和业务规则。相对而言,这是MVC中比较稳定的部分,一般成品后不会改变。 开发初期的最重要任务,主要也是实现Model的部分。这一部分写得好,后面就可以改得少,开发起来就快。
  • View是指视图,也就是呈现给用户的一个界面,是model的具体表现形式,也是收集用户输入的地方。 如你在某个博客上看到的某一篇文章,就是某个Post类的表现形式。 View的目的在于提供与用户交互的界面。换句话说,对于用户而言,只有View是可见的、可操作的。 事实上也是如此,你不会让用户看到Model,更不会让他直接操作Model。 你只会让用户看到你想让他看的内容。 这就是View要做的事,他往往是MVC中变化频繁的部分,也是客户经常要求改来改去的地方。 今天你可能会以一种形式来展示你的博文,明天可能就变成别的表现形式了。
  • Contorller指的是控制器,主要负责与model和view打交道。 换句话说,model和view之间一般不直接打交道,他们老死不相往来。view中不会对model作任何操作, model不会输出任何用于表现的东西,如HTML代码等。这俩甩手不干了,那总得有人来干吧,只能Controller上了。Contorller用于决定使用哪些Model,对Model执行什么操作,为视图准备哪些数据,是MVC中沟通的桥梁。

对于MVC中三者的划分并没有十分明晰的定义和界线。MVC设计模式只是一种指导思想, 让你按照model, view, controller三个方面来描述你的应用,并通过三者的交互,使应用功能得以正常运转。

1.View的几个原则:
其中,View的部分比较明确,就是负责显示嘛。一切与显示界面无关的东西,都不应该出现在View里面。 因此,View中一般不会出现复杂的判断语句,不会出现复杂的运算过程。 对于PHP的Web应用而言,毫无疑问,HTML是View中的主要内容。这是关于View的几个原则:
  • 负责显示界面,以HTML为主;
  • 一般没有复杂的判断语句或运算过程,可以有简单的循环语句、格式化语句。 比如,一般博客首页的文章列表,就是一种循环结构;
  • 从不调用Model的写方法。也就是说,View只从Model获取数据,而不直接改写Model,所以我们说他们老死不相往来。
  • 一般没有任何准备数据的代码,如查询数据库、组合成一定格式的字符串等。 这些一般放在Controller里面,并以变量的形式传给视图。 也就是说,视图里面要用到的数据,都是拿来就能直接用的变量。

2.Model的几个原则:
对于Model而言,最主要就是保存事物的信息,表征事物的行为和对他可以进行的操作。 比如,Post类必然有一个用于保存博客文章标题的title属性,必然有一个删除的操作,这都是Model的内容。 以下是关于Model的几个原则:
  • 数据、行为、方法是Model的主要内容;
  • 实际工作中,Model是MVC中代码量最大,逻辑最复杂的地方,因为关于应用的大量的业务逻辑也要在这里面表示
  • Model所提供的数据都是原始数据。也就是说,不带有任何表现层的代码。 比如,一般不会在输出的数据中添加HTML标签,这是View的工作。 但是Model可以提供有结构的数据,数组结构、队列结构、乃至其他Model等。 这个结构并非是表现层的格式,而是数据在内存中的表现。
  • 与输出不同,Model的输入数据,可以是带有表现格式的数据。 如将一篇文章保存到Post里面,内容中必然包含各种HTML标签。 因此,Model一般要对输入数据作过滤、验证和规范化等预处理。 特别是对于需要保存进数据库的,一定要对所有的输入数据作预处理。 这些预处理,有的其实是业务逻辑。比如只有主编才可以删除文章,这一验证规则既也是业务逻辑,也是权限控制。 而有些预处理,则不属于业务逻辑,比如,文章标题前后的空格应去除。
  • 注意与Controller区分开。Model是处理业务方面的逻辑,Controller只是简单的协调Model和View之间的关系, 只要是与业务有关的,就该放在Model里面。好的设计,应当是胖Model,瘦Controller。

3.Controller的几个原则:
对于Controller,主要是响应用户请求,决定使用什么视图,需要准备什么数据用来显示。 以下是有关Controller的设计原则:
  • 用于处理用户请求。 因此,对于reqeust的访问代码应该放在Controller里面,比如 $_GET $_POST 等。但仅限于获取用户请求数据,不应该对数据有任何操作或预处理,这些工作应该交由Models来完成。
  • 调用Models的读方法,获取数据,直接传递给视图,供显示。 当涉及到多个Model时,有关的逻辑应当交给Model来完成。
  • 调用Models的类方法,对Models进行写操作。
  • 调用视图渲染函数等,形成对用户Reqeust的Response。

三.Model设计参考
在MVC中,Model排第一,是有一定暗示的。
一是Model是整个架构中,代码量最大,复用程度最高, 也是最体现程序员设计功力的地方
二是View和Controller相对于Model而言,在实际开发中,复用程度不高,逻辑复杂程度较低。 可以说,Model设计得好,整个MVC就好,应用开发起就顺。
因此,这一节将以Model为核心,来讲MVC的设计。 实话说,MVC尽管提出了Model View Controller的划分思想,但到了具体实操中,并不是很好把握的。 下面介绍的设计参考,也仅仅是个人在实际项目中的一些体会和想法,仅作参考。

在具体设计中,可以后把握这么几点:

1.Model应当集中整个应用的数据和业务逻辑
应用当中涉及到的所有业务对象都应尽可能抽像成Model。 如,博客系统当中,文章要抽象成Post,评论要抽象成Comment。 而相关的业务逻辑,如发布新文章可以用 Post::create() ,删除评论可以用 Comment::delete() 。 这样子整个应用就显得很清晰明了。

2.基础Model应当尽可能细化
在一个应用中,特别是对于大型复杂应用,Model间关系可能比较复杂。在构造应用时,特别是基础Model时, 要从足够小的粒度来设计。 此时,就要考虑采取继承、封装等措施了。
比如,一个博客文章Post,一般包含了若干标签,在页上一般写在作者、日期等Post字段的旁边。 从逻辑上来看,把标签作为Post的一个属性,是说得通的。 但是如果把标签作为一个属性像标题、正文等字段一样依附于Post。那么在有的功能上,实现起来是有难度的。 比如,客户要求,当一个Post含有标签 “yii, model” 时,可以点击 “yii” , 然后系统列出所有具标签中含有 “yii” 的文章。
为了实现这个功能,正确的设计是单独将标签抽象成Tag。这样,Post和Tag是多对多的关系, 即一个Post有多个Tag,一个Tag也对应多个Post。这个多对多关系可以通过一张数据表 tbl_post_tag 来表示。 接下来,为Post增加 Post::getTags() 方法,并通过 tbl_post_tag 表来查询当前Post的所有标签。 同时,为Tag增加 Tag::getPosts() 方法,也通过 tbl_post_tag 表来查询当前Tag对应的文章。 这样,就具备了实现客户要求的新功能的基础。
因此,在Model设计上,要以尽量小的粒度进行设计。一般而言,粒度越小,复用的可能性就越高。
有的读者可能会问了,既然要求粒度尽可能地小,那么,Post是不是也应当再细化,把段落抽象为Model? 是否有这个必要,看客户需求。一般情况确实没有这必要,如果这么做,那是不是再以句子为单位进行抽象? 但如果客户要求这个博客系统的评论是针对段落进行的评论的, 要将评论显示在对应的段落旁边,甚至显示每个段落评论人次等功能。那么就需要把段落抽象成Model了。

3.分层次设计Model
从设计流程上,数据库结构设计与Model的设计是紧密相关的。先有数据库结构设计,后有Model设计。在设计数据库结构的时候,也是在设计Model。一般而言,最单元、粒度最小的Model就是根据每个数据库表所生成的Model,这往往是个Active Record(活动记录,是一种领域模型模式,特点是一个模型类对应关系型数据库中的一个表,而模型类的一个实例对应表中的一行记录)。
比如标签的问题,在数据库存储过程中,Post和Tag是分开存的,而且这两个表的字段,没有冗余.tbl_post_tag表也只记录他们的ID,没有实质内容。
在获取数据渲染视图,向用户展现时,这两个Model及他们的字段,是完全够用,且没有冗余的。
那么,能不能说 Post 和 Tag 这两个Model是够用的呢?显然还不够。
当用户在创建文章、修改文章、审核文章时,需要采用一个表单来显示来收集用户输入。 其中,对于标签的采集,一般是一个长条的文本框,让用户一次性输入多个标签,并以 , 等进行分隔的。
但是,这个文本框没有一个字段与之进行对应。我们也没办法对这个字段的用户输入进行任何的验证、预处理。
因此,Post的功能是不够用的。不够用怎么办?那就加吧。但直接在 Post 里面加个 public $tagString 并不好。 毕竟只是在使用表单时,才会有这个问题,其他场合,这个字段是没用的。
这种情况下,一般使用继承:
public class PostForm extends Post{ public $tagString; ... ...}
这样,当控制器发现用户在创建、修改、审核文章时,可以使用 PostForm Model来渲染视图了, 而其他场合则仍使用Post。这样就在需要时,增加了一个tagString的字段用于收集用户输入的标签。
在具体设计过程中,由于Model本身就会包含很多代码,因此,要多使用这继承等手段,把代码组织好。

4.仔细为Model方法命名
由于Model的代码量比较大,又集中了大量的逻辑,因此,会在一个Model中有大量的方法。仍然以Post为例, 会涉及到创建、审核、发布、回收等流程,相关的方法比较多,在命名上要用心。 可能会涉及到的、名字又比较接近的方法就有:
  • getPrevPost(),前一篇文章,用于导航
  • getNextPost(),下一篇文章,用于导航
  • getRelatedPosts($n = 10),获取相关的N篇文章,用于相关文章推荐列表
  • getPostsOfAuthor($n = 10),获取同一作者的N篇相关文章,用于作者文章列表
  • getLatestPosts($n = 10),最新的N篇文章,静态方法,用于文章列表或RSS输出
  • getHotestPosts($n = 10),最热门的N篇文章,静态方法,用于热门文章列表
  • getPublishPosts($n = -1),获取已经发布的N篇文章,静态方法,用于文章列表
  • getDraftPosts($n = -1),获取未发布的N篇文章,静态方法,用于作者页面
这里只是一些获取其他Post的方法,命名比较合理,一看就知道意思。 而且全部写成getter的形式,可以使用读取属性的方式进行访问。
不单单是在Model方法的命名上要用心, 在变量名、类名、方法名等的命名上,也要养成习惯,形成规律。 不要图一时之快,胡乱起名。否则,出来混,迟早要还的。

5.MVC与前后端的配合
从MVC的起源来讲,是从桌面应用的开发中发展起来的。从本质来讲,这是一种解决问题的思路和办法。 从实践来讲,这是一种久经考验的有效方式。但是如开头我们讲的,Yii更多的是侧重于后端。 对于Web应用而言,包含Yii在内的许多Web开发框架,都是没有办法知道用户的操作,如鼠标、键盘等操作的。 Web应用想要了解用户的操作,只能依靠用户发送Request。 而对于鼠标、键盘等的响应,只能依靠前端技术,如JavaScript等来实现。
再加上这几年来Web浏览器的功能日臻强大。因此,Web应用开发出现了一个新的发展苗头,就是功能从后端往前端转移。
在前端,通过JavaScript捕获用户操作,进行相应处理。 或是发送回后端获取响应后处理,如通过ajax请求后端数据,实现无刷新的局部页面更新,向用户进行反馈; 或直接在前端由浏览器进行处理,如使用backbone.js、Angular.js等前端框架的数据绑定功能等。 这些都使得Web应用表现得越来越像桌面应用。
后端MVC也在为前后端的发展而改变。 Controller的功能更多的变成了识别是ajax请求还是普通请求, 并根据请求的不同采取相应的视图渲染方式。对于普通请求,正常渲染视图,输出HTML。 对于ajax请求,则返回局部渲染视图,输出HTML片段。有的甚至输出XML或者JSON。唯一在大潮流中,巍然不动的,还是我们的大Model。

四.总结:
对于MVC中三者的划分并没有十分明晰的定义和界线。
MVC设计模式只是一种指导思想来描述你的应用,在实际应用中,尽量规范

Model:
考验程序猿功底,根据业务逻辑返还对应数据,可复用,成型后改动最少的地方
1.大量的业务逻辑【有分出来写的,logic层】
2.提供原始数据【查询数据库操作】
View:
目的在于提供与用户交互的界面,改动最频繁的地方
Contorller:
用于决定使用哪些Model,以什么格式渲染返回,是MVC中沟通的桥梁
1.接受request参数,但不做处理(严格上来说哈但有时也会改)
2.为视图所需要数据调用对应Model,
3.根据请求的不同采取相应的视图渲染方式(html or ajax的json/xml)

©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值