MVC架构在Discuz!插件开发的应用【附PPT下载地址】

 

MVC架构在Discuz!插件开发的应用《转》
说明
本PPT所阐述内容已经在个人能力范围内，对其科学性、安全性、正确性、完整性、及时性、合法性等做义务管理和初步检验，但均不做任何承诺和担保。

本人对MVC的理解也是非常片面和不全，《转》欢迎各位与本人探讨。邮箱： horseluke@126.com
目录
01. 何谓MVC架构——引子
引子：从路边小吃摊到豪华酒店的经营之路
最初经营路边小吃摊：
一个人要负责：接受顾客下单、炒菜、端到桌边服务顾客
接着有了资本后开了间小小的粤菜馆，此时多了几个服务员和炒菜的师傅：
服务员接受顾客的下单（有时候还跑去仓库里面看看还有没有某种具体的原材料）和把师傅炒好的菜端上桌面
师傅就只管拿到订单后炒菜，或者告知，没有这个菜可炒
有时候老板亲自出马，接受顾客下单和到厨房炒菜
假如经营有方外加机遇，最后发展成豪华酒店：
服务员接受顾客的下单（不允许进厨房和仓库）和把师傅炒好的菜端上桌面；
师傅就只管拿到订单后炒菜，或者告知，没有这个菜可炒
老板不用做具体业务了，只管战略建设、人力资源建设......
01. 何谓MVC架构——引子
软件开发也是如此。
最初，一个页面混杂PHP代码和HTML代码；
意识到应该两者分离（厨房归厨房大厅归大厅）。但是PHP代码还是过于庞大和难以阅读（比如，服务员越俎代庖，跑去仓库看还剩多少原材料）；
现在PHP代码也要进行分离，一个负责业务操作（M层，对应引子，只有厨师才能直接去仓库里面拿原材料炒菜），另一个负责请求处理和HTML模版渲染（C层，对应引子，服务员不能知道仓库里面还剩多少原材料，只接受订单和端菜上桌）。这就是有MVC的思想在里面了。
01. 何谓MVC架构——概念
MVC（Model View Controller，即模型－视图－控制器）是一种软件设计模式。[1]

它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。[2][3][4]

01. 何谓MVC架构——概念
模型（Model）：负责应用程序的业务规则。封装访问数据库的方法并提供一个可重用的类库。模型不关心它是怎么被操作（不依赖于控制器）和如何显示数据（不依赖于视图）。它只是提供“中立”的数据。
视图（View）：控制数据的外观并且提供从用户收集数据的机制。
控制器（Controller）：起到不同层面间的组织作用，并控制程序的流程。
01. 何谓MVC架构——概念
02. 与Discuz!的相容设计——疑问与解答
疑问1：是否做一个Discuz!架构下的多余架构（“ windows 下的linux”）？[5]
个人回答是“否”。原因如下：
MVC只是一种设计思想，与任何具体程序无关；
Discuz!的架构确实已经涵盖了许多方面，但是仍有许多改进的地方，比如版块权限检查，就非常分散。
一个反例：到了Discuz! 6.1时代，作为用户管理和通行证的部分为啥要独立为一个UCenter（同样也是MVC架构）出来呢？
02. 与Discuz!的相容设计——疑问与解答
疑问2：插件用MVC是否“小题大做”？
个人回答是“根据实际情况”。原因如下：
对于个人开发的仅有一个或者几个明确功能的插件，以原来的方式开发也无不妥；
假如考虑到多人开发、或者考虑到以后可能需要增加新功能、或者考虑到各个插件之间类库的重用性，MVC不失为一种选择。
注意：前期设计很重要也很花费时间，若觉得耗费不起或者需要赶工，那么不用也罢。
02. 与Discuz!的相容设计——实现方式
第一种：完全独立外挂型
MVC架构部分：
全部自己编写
期间不用或者很少使用Discuz!提供的函数和类库
单一入口文件部分：
放在论坛根目录下
只是用于引入Discuz!的include/common.inc.php文件（甚至不引入）和框架的初始化文件：
02. 与Discuz!的相容设计——实现方式
第一种：完全独立外挂型
此方式受到Discuz!的影响最小；
耗费时间最大——可能会陷入重建论坛框架的无边苦海中（这事情应该由官方来做）；
故不太推荐此种方式
02. 与Discuz!的相容设计——实现方式
第二种：运用论坛已有架构型（1）
MVC架构部分：
M层和C层写成类库，并根据实际情况使用Discuz!提供的函数和类库
不需要写V层，使用Discuz!提供的模板引擎技术。但由于Discuz!的View层太过强大且与面向对象设计部分相冲突，因此不在C层启动，而是在C层接近运行完毕时，以某种方式define一个常量；最后单一入口文件检查到常量并进行View层启动。
单一入口文件部分：
既充当初始化框架资源，同时灵活引入部分Discuz!的资源；
既可放在论坛根目录下（此时需要自行引入文件/include/common.inc.php），也可与plugin.php捆绑启动（需要遵循Discuz!插件设计原则）；
启动Discuz! View层。
02. 与Discuz!的相容设计——实现方式
第二种：运用论坛已有架构型（1）
例子：插件会员查看其他用户主题和回复For 7.1（单一入口文件与plugin.php捆绑启动方式）及For 7.0版本（单一入口文件放在论坛根目录下）。
View层的启动方式（以该插件的7.1版本说明）：
Controller运行到最后，$this->display('模板名')，此时将define一个常量'APP_TPL_FILENAME'，值就是'模板名'。
Controller运行结束，控制权返回到单一入口文件（7.1版本为plugins/iirs_userPostList/frontLoader.inc.php）。
单一入口文件检查是否存在此常量，然后启动V层：
02. 与Discuz!的相容设计——实现方式
第二种：运用论坛已有架构型（1）
在灵活性和相容性取得较好的平衡。
但可能难以迁移到PHP4平台。文件比较多和分散。
个人较为推荐使用。
02. 与Discuz!的相容设计——实现方式
第三种：运用论坛已有架构型（2）
MVC架构部分：
M层设计与“第二种：运用论坛已有架构型（1）”差不多；
但是C层完全遵循Discuz!插件设计原则，使用面向过程的写法（在此之前还可能需要引入某个文件初始化框架资源），以xxxxxx.inc.php放在指定的插件目录内。
此时，V层的写法和Discuz!给出的写法一样。（见下一页的代码）
单一入口文件部分：
由Discuz!文件plugin.php处理。因此，不需要编写。
02. 与Discuz!的相容设计——实现方式
第三种：运用论坛已有架构型（2）
例子：前台文件：plugins/iirs_ demo3/userController.inc.php
02. 与Discuz!的相容设计——实现方式
第三种：运用论坛已有架构型（2）
与Discuz!和PHP4的相容性最好；
C层需要在插件后台的设计中进行指定（必须填写程序模块名称，和指定为红框所示的几个模块类型），灵活性不足。
03. 其它问题
问题：处理Discuz!的cache
Discuz!的Cache没有统一的格式，基本上引入一个Cache就产生了一个新的变量。这样的结果使得不同的Model实例在引入相同的缓存时产生了困难。如文献[6]提到的引入语言包缓存问题。
解决方法有，定义一个函数（或类静态方法），里面有一个static变量，然后由它来加载缓存（加载时存储到这个static变量中）和提供缓存数据。
熟悉Zend Framework框架的开发者可通过使用、修改和扩展Zend_Registry类来达到目的。
【PPT下载地址】 http://bbs.php100.com/job.php?action=download&aid=4127