PHP发明人谈MVC和网站设计架构貌似他不支持php用mvc

2024-05-04 22:07:20

字体：大中小

来源：转载

供稿：网友

Q：越来越多Web 2.0网站走向应用平台，你认为打造这类平台的关键为何？

A：简单来看，应用平台就是API，任何Ajax或 Web 2.0类型的网站，都是在应用平台上运用了API来创造出视觉介面的互动效果。例如Yahoo Mail，透过简单的Request呼叫，来读取後续的信件。打造这类网站，如何规画解决问题的方式，会决定了网站未来的扩充性（Scalability），而非效能决定网站的发展。

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

上一篇：php学习笔记之函数声明(二)

下一篇：php smarty 二级分类代码和模版循环例子