PHP网站MVC架构方式中的种种误区

PHP网站MVC架构模式中的种种误区
MVC架构模式已不再是新技术，也不再是新名词。但是，如果你能大概看一看因内的开源的PHP开发框架，或者国内的PHP开源软件。我们不难发现，很多这们的代码与其说是MVC，还不如称其为东施效颦。很多是为MVC而MVC。或者，只提供MVC的部分功能。而不是真正意义上的MVC。这其中，很多原因当然是软件开发者不懂得设计模式，不了解MVC的根本目的。
由此，我们先明确一下，MVC的根本目的有哪些：
1、分工：使用MVC可以把数据库开发，程序业务逻辑开发，页面开发分开。
多数人说起MVC的好处，仅限于这一点。认为，MVC不外乎是利于大型团队合作。其实是大错特错了。
2、松耦合。如果不懂得设计模式，根本不知松耦合是什么意思。当然，可以简单说明一下：
我们把模块部分，分为数据库抽象层，数据操作层，和业务逻辑层。这是最简单的业务架构。这样分开的好处是什么？
数据库抽象层，一般会支持多种数据库。这样做的目的，是可以让你的应用快速更换数据库。也能方便你的应用与其它类型数据库交互。
同时，更强大的，还会有链接管理器，从而对大型网站的分库操作，分表操作的支持。
一般，数据库抽象层可以通过向导生成静成的ORM层，或直接提供动态的ORM层（这是最新的DRYSQL模式）。
但除了ORM，CRUD，还有其它的查询。MVC中仍是要求将其写到专门的数据操作模块中的。
为什么要这样做呢？这就是松耦合。当一部分改动，不会影响另一部分。
试想，如果将数据模块与业务模块混合在一起，那么，如果某一日更换数据库，则，你要修改的是庞大的模块部分的代码。但将数据模块独立出来，只要修改数据模块部分的SQL语句即可以了。
对于视图部分，实际也是一样。因为，本来是给PC浏览器用的，如果哪一天要加上手机页面，则只要添加就可以了，其它的都可以共用，但若不分开，就得重新做一套。
从这一点看，有人说，PHP不适合于使用框架，实际上，不用框架，很多是行不通的。
可以看出其目标：这也就实现了，出现问题只要修改一处。而不是修改多处。
3、共享与集中处理。
控制器，是一个完全将流程按面向对象方式设计的程序流程中的组件。我们应当能够记得，最普通的PHP程序写法，页头包含SESSION模块，然后是访问控制。但若想，增加对主机名，子域名控制，则每一个包含的页面，都要再次增加包含。或要在SESSION模块，或访问控制模块增加一个包含文件。于是，程序逻辑变得相当混乱。如果其中有出错与跳转，那么，势必会出现在不需要加载的页面跳来跳去。
控制器的目的，就是让页面请求最终到达所需要的页面。并且是基于面向对象的流程的。
通常：控制器，必须要有Host， SubDomain， IP，URL，ACL的路由检测。由于现在一个网站，同时有浏览器与手机的，所以，还要有UserAgent检测。控制器要能做到最为方便地将一个请求映射到一个模块类的一个方法（事件）中。
4、完全面向对象
MVC程序，多数只有一个客户端请求入口――bootstrap，应用往往基于这个文件进行配置或修改。其它的全部都是class。即实现客户端到服务器端的事件映射。这样做的目的，是将应用的流程规范到了一个完全面向对象的流程中。保证程序的可读性，从而保证与程序员的无关性。
5、目前流行的开放API
如果是良好的MVC架构，开放API只要直接调用数据操作层接口就能实现，这也大大节省了程序的开发量，同时增加了代码的公用与集中处理的能力。这也就实现了，出现问题只要修改一处。
6、视图问题：因为界面的需求是多样的，不断变化的，往往对于WEB模式的企业应用更加显示出这样的变化。目前，可悲的是，PHP仍没有象.net,或flex相似的视图模式。只有JAVA，有Typstray,JFS这样的面向部件的视图模式，PHP目前均没有成熟的开源产品可用。虽说，Smarty抄袭了struts,phpFACES抄袭了JFS，但是本质上，均没有完全体充分利用PHP的语言的长处。phpFACES则更是无人问津，国内几乎无人使用。而FLAX RIA的冲击，以及JS框架带来的RIA新技术，也没有能与后端PHP相结合。JSP落后，PHP一样也是落后。人们需要新的开源。当然，phpFACES可以说是这方面的先驱，因为，它是基于DOJO创建的组件库。
7、插件技术：一个好的开发框架。所有的扩展应当均是由插件式方来完成的。但现在有多少框架支持插件？官方的Zend可以说是大全，而不是插件式配置，这纯属是技术误导。当然，最好的，插件最多的，则是symfony. 而symfony的ORM还在使用Propel，没能用上最新的DRYSQL技术。就插件而言，很多情况下限制了软件的应用，推广与发展，比如，大名鼎鼎的WordPress,提供了完美的应用插件，但底层开发框架极为混乱。最简单的，只能用于Mysql数据库，谁要是想用Oracle，那你的恶梦就开始了。所以，一个好的框架，应当在任何一个层面均支持插件。插件由此可以大概分为：数据库驱动插件，数据模块插件，缓存驱动插件，图型库插件等功能类插件，同时还有应用类插件。现时代，没有插件技术，就没有成功可言。也只有支持插件，才能够实现无限扩展，通用性才不是空话。但是，从国内行业论坛上来看，没有专门讨论插件接口实现技术的相关的话题，高处不胜寒！！
8、开发框架的架构：一个WEB应用架构，其内核应当是一个好的开发框架，这一个框架，必须要有的核心是：App对象，一个给入口文件用来完成一切事务的聚合类，AutoLoader 装载器，uxConfig 配置文件读取，uxLocale 本地化管理，Model 模型，View 视图，Controller 控制器（主机，子域名，URI，UA，IP，ACL均需要支持），Exception ErrorHandle错误与异常管理，Security 安全管理（Validator 数据验证，Filter 数据过滤器）状态管理（Session 会话管理，Cache 缓存管理）。然后是应用必须的基本类库，其中，数据库排第一位。架构中所以把数据库放到类库而不是放到内核，主要是两个方面，其一，让用户有选择权，用户可以选择用框架本身的，也可以去选ADODB，DOCTRINE，PEOPEL等第三方的。其次，网站规模的变化，数据库层面变化是最快的。但现在有多少开发框架有这样的规范的架构？
由此，我们发现：MVC架构模式中的种种误区不外乎来源于两个方面：
其一是：人们的认识造成的。PHP开发队伍技术落后，素质差是一大本质原因。对软件架构的不了解，特别是面向对象，设计模式的不了解，从而无法深入理解MVC。
这与PHP自身发展也有关系，PHP4以前，是不支持面向对象的。PHP是以简易吸引了大量用户。但一旦用于大型网站开发，对于这此嫌JSP烦锁的人，恶梦就开始了。
其二是：PHP开发框架发以及开源技术发展密切相关的，开发框架对MVC不能提供足够好的MVC架构支持，同时，没有足够好的开源组件，使得人们不能进一步理解MVC。如同，你用了PHP的ADODB，但它也不会要求你在程序中，要把数据模块与业务模块分开。这是架构师的责任。然而，中国PHP行业有多少网络应用架构师？比如，敏捷之履上海活动时，杭州某大公司的某外籍CTO大讲特讲PHP根本不需要框架，云云，这不能不反映出国内PHP行业技术的落后。现实是如此残酷。唯有正视软件产业的现状。