MVC架构在Discuz插件开发的应用.pptVIP

MVC架构在Discuz!插件开发的应用 Horse Luke 2009-11-14 说明 本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!的资源