最近公司的业务比较繁忙,随着网站的增加,为每一个网站增加一个目录看起来就非常臃肿和烦琐了,而且如果基本框架更新的话,还要麻烦的为每个站点去更新后台.网站无非就是前台,后台,数据库.我总希望这个后台可以函概所有的功能,那么做一批站点只需要修改相应的前台调取文件就可以了,所以不可避免的想到了MVC模式以及单入口模式.

下面是我总结的单入口模式的好处:
1.单一入口的例子也很多,如WP,mambo以及DZ后台,这样子其实比较好管理,管理起来方便统一.
2.还有一个好处就是权限方面可以很好的分配,如果把module和action的权限按照数组的形式存放在数据库里,是不是对权限的操作更灵活,更强大.
3.还有一个好处是网站跟目录看起来简洁.
4.还有一个好处是一个框架可以开发无限个网站,试想,如果index.php,article.php都放在跟目录下,那么只能放一个项目,如果是单一入口,模块根据项目名称放在不同的目录下,index.php根据项目名称掉区不同目录下的5.php文件,岂不是美哉?
6.单入口还有一个好处就是容易规划mod rewrite,可以写一个规则出来,相对方便一些.
7.还有一个好处,如果不允许rewrite,那么我创建静态目录,如果跟目录程序多,则加上静态文件更会繁杂,不好整理.如果是单一入口,清洁方便.

单入口最头疼的问题就是操作的不习惯以及运行的效率.至少从现在看来,我是比较喜欢单入口的MVC模式.

MVC的原型
MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

JAVA中的MVC
JAVA把MVC引入了Web领域，并在此基础上架构出了一套称为Model2的体系。由于Web的特殊性，JAVA中的MVC和Desktop中的MVC并不完全一致。主要原因是Web中的V不是持续的，用户每访问一次，V就要重新生成一次，所以V始终是和M一致的，不需要C来控制同步。那么JAVA中的C在干什么？JAVA中的C通常用于流程的转向，其实用的是Dispatch模式，不再是Desktop中的C了。

PHP中的MVC
要在PHP中原封不动的COPY JAVA的MVC是不可能的。问题主要表现在M上，在JAVA中，M是独立于业务逻辑和表现逻辑的数据模型，在服务器端跨页面存在，JAVA Bean扮演的就是这个脚色。而PHP进程并不长时间驻留于内存，只在PHP页面开始执行时创建，在页面解释执行结束时就已经结束。在这样的情况下，我们根本无法直接实现M。所以所有声称实现了MVC模式的PHP程式都只能通过模拟手段来实现M。实现的方式一般是在当前页面结束前把数据存入数据库或者cookie/session，在下一个页面中再透过数据库或者cookie/session重建M。这样的方式和JAVA中的Bean比起来可以说是开销巨大，本来往内存中写数据的简单操作现在要从服务器端传到客户端或者数据库，然后再传回来。与其用这么大的开销来维护一个数据模型再在最后把这个模型塞回数据库，还不如直接根据需要更新数据库里边的数据。

然后我们再来看V。现在很多PHP程序简单的使用了一些模板技术就在说明中写“采用MVC架构”。其实绝大多数的PHP模板程序都只是分离HTML和PHP的，而非MVC强调的显示逻辑和业务逻辑分离。一个混用HTML和PHP的页面一样可以是MVC的一部份。如何分离显示逻辑和业务逻辑至今没有一个满意的方案。我个人则比较认同http://www.phpe.net/articles/384.shtml的实现方案。至于C，和JAVA中差不多，还是被用作转向，这个在PHP中其实并不重要。

一个极耗资源的M + 一个区别不大的V + 可有可无的C 构成了PHP中所谓的MVC。

在网上发现一句有意思的话: MVC: 模型(Model) - 数据库, 视图(View) - 模板, 控制器(Controller) - PHP脚本.

很必要抽出点时间看下MVC的运行效率,收集一下比较好的MVC框架:
zend,thinkphp,CodeIgniter