最开始就是MVC和大量__autoload，后来发现性能太菜，渲染一个页面竟然要超过10ms甚至要20ms，太丢人。

这样不就跟StartBBS之类的性能非常低下的BBS差不多了？

我就拆掉重写成这样了，OOP也是能不用尽量不用——因为代价巨大，特别是对于内存，大量使用OOP的话每个页面消耗的内存甚至可能超过1MiB。

如果首页和主题页面执行时间超过10ms，并且内存消耗超过1MiB，在目前这个量级下实在是非常丢人的一个数值。

目前就是Rewrite充当Controller，Model在根目录下，对应style里的多套View，也算实现了简易的MVC分离。

可能对于只会用文盲版MVC框架的PHP菜鸟来说，阅读会比较困难；但是对于有PHP基础的人，不需要文档就可以非常轻易地理解整个程序。

转发一段PHP之父 Rasmus Lerdorf 关于MVC的见解给你学习一番：

Q：如何规画网站架构，才会具有扩充性？

A：将一个网站应用，分成几十个独立小程式，前端透过 API提供服务，后端是应用程式引擎，这样做自然会有扩充性。因为应用的每一个部分，都有不同等级的使用方式，需要有不同的扩充程度（scaling level），需要不同的机制来处理。以开发Yahoo Mail而言，是要开发一个地址服务程式、一个读信服务、一个送信服务，而送信程式完全和读信程式无关。以Yahoo的规模而言，需要让这些工作完全分离，才有扩充性。

Q：这种规画网站的方式，什麽是最重要的关键？

A：关键是你必须建立分离、模组化的独立端点，而不是全部放在同一个大篮子裡。大多数现今MVC架构（MVC framework）的开发框架（Framework），使用所谓的前端控制器（Front Control），每一次浏览器提出Request请求时，就会呼叫这个前端控制器，再由前端控制器来分辨，使用者想要执行哪一支程式。这样做，一点意义都没有。

在浏览器层次，程式完全能知道使用者想要做什麽事情，例如使用者只是要读信，程式就不用再把需求送到伺服器，让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器，由伺服器处理，就会浪费大量伺服器资源，来处理那些对使用者没有实际功用的工作。扩充性来自架构，很多开发框架，将所有事情绑在一起，限制了架构。选错开发框架，你就没有扩充性。

Q：你是说MVC模式不利于网站扩充性？

A：MVC模式比较适合用在网页控制器（Page Control）的层次。基本上，每一个网页控制器都是独立模组，读信和查地址是不同的网页控制器，所以，读信程式就不会干扰到查地址程式。所以，在每一个端点使用MVC模式来打造小型的网页控制器，是不会有问题。但是，大多数採用MVC模式的框架，预设在网站中採用前端控制器，而非用网页控制器的方式，这样的MVC模式，只适合在小型或单一伺服器的网站。

Q：你会如何选择开发框架呢？

A：一个框架都不要用。但是，我会从这些开发框架中，找出我需要的功能，拿出那个我需要的程式模组来用，或者参考其中的设计想法，而不是套用整个框架。我所看到的大多数框架，都没有专注在打造有效能的扩充性和可模组性。

Q：难道开发者不需要框架或架构吗？

A：网站的确需要有架构，每一个人都需要框架，框架是一种解决问题的方法。但是你并不需要通用型框架，用一个前端控制器，来解决所有问题，这样通常没办法成功。每一个问题都不同，你需要引导框架，使用正确的设计模式，直接解决真正要处理的问题。只生产一款汽车，怎麽可能满足全世界人的需求！

用框架开发雏形系统就好，但真正的产品就不要全部套用。从框架开始比较容易，但你要拆开全部的框架，移除Runtime检查、拿掉不需要的功能，只留下你会用到的程式模组。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介于两者之间。

回复#2 @lincanbin :

极是

楼主点名批评了StartBBS

StartBBS性能低下，是不是因为他使用了CI框架呢？

但是CI又号称是框架中性能比较靠前的呢？

回复#4 @osalee :

啊对，还有其他性能更低下的框架，但是我没有针对哪些程序的意思，只是指出一个事实。

回复#5 @lincanbin :

我现在也回归面向过程的写法了。因为我不需要ORM这类东西，我喜欢手写SQL。

楼主有测试过用框架的路由与纯rewrite这种方式性能大概差多少？只针对路由方面。

回复#6 @osalee :

我记得一个空白的CI消耗的资源，跟我现在网站整个首页消耗的资源差不多，都要2ms，甚至更多，详细的没测试。

代码写到一定的阶段  只有实战性才能检验出程序的价值