传统的面相过程式的开发方式在处理中型以上的应用时，就开始显得力不从心。即便我们能够快速的完成需求，但是在需求发生变更后或者进行后期维护的时候，我们会深深地陷入我们早期搭建的陷阱中。所以，使用面向对象的方式来实现MVC模式，将为我们梳理程序的架构提供一个清晰的思路。
什么是MVC？
关于MVC的定义和解释，可以说多种多样。我们可以在Wiki或者[2]中找到更为详尽的解释，这里我并不打算，也没有能力进行深入的讲解，从PHP开发的角度来讲，MVC可以概括为：
视图(The View)：
一说到视图，我们很多人都会想到模板引擎(诸如Smarty等等)。其实就是各种各样的输出，比如说html模板和Javascript文件等。
模块(The Model)
模块代表了程序的逻辑，在企业应用中通常称为业务逻辑层。一般来讲，这一层完成的工作是把原始的数据处理成按照我们设计的数据结构存储的有意义的数据序列，并将这些数据交给视图去处理。通常情况下， 模块中会利用一个数据抽象类来进行与数据操作有关的处理。
Model通常包含了哪些用来同数据库打交道的函数。
控制器(The Controller)
控制器使所有WEB应用的第一站，他接受收到的参数，比如$_GET变量，然后做出相应的反应。
关于MVC的是否适合PHP的争论也很多，人们不断的讨论MVC是否适合PHP[3]，现在也已经有了很多的MVC框架，诸如PHP MVC Frameworks中列出的[4]。那么，为什么人们这么热衷于MVC，我们为什么要使用MVC在我们的设计中呢。
为什么用MVC？
MVC最早是用来解决桌面GUI的编程问题，最早的MVC框架应该是Sun在1999年提出的Model 2，后来演变成了Struts。MVC带给人们深刻的印象，但是我们在使用的过程中，却并没有认真的想过为什么使用MVC。
在传统的桌面应用中，一旦Model中有时间发生，我们可以主动的让View界面进行刷新，从而展示后台发生的变化。而在Web应用中，我们似乎限于传统的Http的Request/Response的方式，我们似乎没有办法让用户端进行更新。这一段讨论，并不是认为MVC不能够用来进行WEB应用的开发，而是觉得从某种程度上来说，他还不是最合适的。
关于使用MVC的争论还有很多[1]，但是相信所有习惯了使用MVC来组织自己的项目的人，让他选择一个新的项目构架时，一定不会放弃MVC。
- 共2页:
- 上一页
- 1
- 2
- 下一页
