PHP发明人谈MVC和网站设计架构

PHP发明人谈MVC和网站设计架构

ID:37922911

大小:22.50 KB

页数:4页

时间:2019-06-02

PHP发明人谈MVC和网站设计架构_第1页
PHP发明人谈MVC和网站设计架构_第2页
PHP发明人谈MVC和网站设计架构_第3页
PHP发明人谈MVC和网站设计架构_第4页
资源描述:

《PHP发明人谈MVC和网站设计架构》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、PHP发明人谈MVC和网站设计架构时间:2011-04-1523:28来源:PHP100中文网作者:佚名点击:2769次【字号:大中小】PHP是全世界上使用率最高的网页开发语言,台湾每4个网站,就有1个用PHP语言开发。1995年发明PHP语言的RasmusLerdorf,也是打造出Yahoo全球服务网站的架构师之一,他首度来台分享如何架构网站扩充性丶安全性和效能的秘诀。Q:越来越多Web2.0网站走向应用平PHP是全世界上使用率最高的网页开发语言,台湾每4个网站,就有1个用PHP语言开发。1995年发明PHP语言的RasmusLerdorf,也是打造出Yahoo全球服务

2、网站的架构师之一,他首度来台分享如何架构网站扩充性丶安全性和效能的秘诀。Q:越来越多Web2.0网站走向应用平台,你认为打造这类平台的关键为何?A:简单来看,应用平台就是API,任何Ajax或Web2.0类型的网站,都是在应用平台上运用了API来创造出视觉介面的互动效果。例如YahooMail,透过简单的Request呼叫,来读取後续的信件。打造这类网站,如何规画解决问题的方式,会决定了网站未来的扩充性(Scalability),而非效能决定网站的发展。Q:如何规画网站架构,才会具有扩充性?A:将一个网站应用,分成几十个独立小程式,前端透过API提供服务,後端是应用程式引

3、擎,这样做自然会有扩充性。因为应用的每一个部分,都有不同等级的使用方式,需要有不同的扩充程度(scalinglevel),需要不同的机制来处理。以开发YahooMail而言,是要开发一个地址服务程式丶一个读信服务丶一个送信服务,而送信程式完全和读信程式无关。以Yahoo的规模而言,需要让这些工作完全分离,才有扩充性。Q:这种规画网站的方式,什麽是最重要的关键?A:关键是你必须建立分离丶模组化的独立端点,而不是全部放在同一个大篮子里。大多数现今MVC架构(MVCframework)的开发框架(Framework),使用所谓的前端控制器(FrontControl),每一次浏览

4、器提出Request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义都没有。在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充性来自架构,很多开发框架,将所有事情绑在一起,限制了架构。选错开发框架,你就没有扩充性。Q:你是说MVC模式不利於网站扩充性?A:MVC模式比较适合用在网页控制器(PageControl)的层次。基本上,每一个网

5、页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一个端点使用MVC模式来打造小型的网页控制器,是不会有问题。但是,大多数采用MVC模式的框架,预设在网站中采用前端控制器,而非用网页控制器的方式,这样的MVC模式,只适合在小型或单一伺服器的网站。Q:你会如何选择开发框架呢?A:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。Q:难道开发者不需要框架或架构吗?A:网站的确

6、需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除Runtime检查丶拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介於两者之间。Q:网站需要规画到多久以後的扩充需求?A:我总是痛恨要帮未来

7、考虑太多。当你无法预测未来,你就无法帮未来作决定。网路变化太快,我通常只规画半年内的事情。现在决定半年以後的事情,可能会做出错误决策,反而让事情更糟。如果你没有解决当下的问题,而是想像未来会发生的问题,我认为不值得,我宁可解决眼前看得到的问题,真正聚焦在当下需要的产品。Q:那麽,有任何准则是架构人员可以遵循的吗?A:最主要的原则是,仔细考虑如何分配程式模组,尽可能将程式拆解成更小的元件,调校出适当的API,你应该规画的是使用者端点的事情,例如浏览器请求的类型是什麽?应用程式要如何回应?是否可以切割?是否可以把这些工作分配到完全

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。