技術討論區 > PHP程式設計討論區

php與MVC

頁: (1/5) > >>

kiwikiwi:

有褒有貶

看到一些文章,真的是對php在MVC的發展上有褒有貶。我並不是一個會專注一個程式語言,一種曉以大義的全功能解決方案,然後死扒著他覺得非用他不可的人。儘管我現在的工作需求也確實需要在php上發展MVC。在一開始的時候,我也曾經很認真地去追究Asp.Net, jsp, php的優缺點,並不是為了選出選美皇后,而是想想到底誰適合什麼?

想當然爾,php怎樣也拼不過java或是.Net原本忠實可以呈現MVC模式的環境,那這樣子似乎連我這篇文章都要寫不下去。



其實不是這樣的...
我相信一個語言的存在必定有他的需要,當然我不能斷定說php會死會活,但是以他存在的時間看起來,php確實有他的優點。儘管他的優點(方便上手)也相對帶來的就是,許多設計師並不是真正瞭解程式設計就在寫php,長久發展起來就會造成許多亂七八糟的coding現象,也是相對阻礙了競爭力,最後可能終歸消失在地球上。

但是現在的我對於國內外的php發展狀況,菁英們的想法還是很看好的。他們很多軟體設計觀念都相當正確,幾乎也都不是只有寫過php,絕對跟那些被外包撈資料庫做網頁的不一樣。


我想先談談php的優點。

speed DOES matter

現在的Web2.0,有一半可以說是因為php而催生的,例如說mediawiki做成的Wikipedia,眾多的blog,人數多到不行的無名小站...可以看得出來php不僅是因為好上手,而是因為語言的特性而有彈性,因為函示庫的多樣化讓他在很多地方都可以發揮。而我們仔細觀察php的優缺點,會發現速度也是一個很重要的考量,這包括上手速度,因為他間接了影響推廣所需要的時間,程式語言執行的效率(這要感謝mod_php),間接影響了推廣出去之後真正用的人到底可以多到怎樣的地步。數量大者,影響力便大。

我舉個例子來說好了,要是今天無名用的是java+struts,可能不用等到商業化,在交大裡就已經倒了。並不是說他們絕對寫不出像現在一樣好的系統,而是系統無法同時負載那樣大的人數。所以我都會暱稱.Net和Java是貴族語言,因為只有企業開發負擔的起那樣系統的成本,10個你會看不太出來,1000人以上要用的時候就可以想像系統的負載。

所以php其實是適合輕量化,數量龐大的老百姓需求。例如說blog,討論區,甚至wiki也好。
而我剛剛講的貴族語言比較適合專業,功能強大,安全性高的企業需求。

MVC

此外有關於ORM是否真在php裡適用,其實我也疑惑了很久。但是先要釐清一下Java所謂的ORM,其實是本來就是有將DB原始資料快取在記憶體的功能,就如同.Net的DataSet,也都是會積極進行將資料庫快取在記憶體裡的作法,也是因為這樣才可以跨網頁或視窗存在,Model有兩份的話就糟糕了。在php裡,似乎無法真的將Model的資料快取在記憶體裡,如果是上千筆的資料,可能會造成apache緩慢。

所以實際上在php裡大部分的Framework都是將Model當作方便存取DB的工具,或是拿來解決SQL語法雜亂,並不是如同Java,.Net一般有DB in memory cache的方式。就如同第一個連結裡的最後一個圖,因為DB並不是快取在記憶體,所以一有要求就馬上傳到DB裡去。但是如果你的應用真的是大到不行,對資料的要求也很傷重,那你應該使用cakephp+adodb,adodb就有快取的機制了。也是因為這樣cakephp就有view cache的機制,似乎是想彌補這個缺點。

至於說MVC因為大量產生了物件導向的code,比起以往載入到apache裡的程式碼更多。參考這兩張圖:

我將同一個專案用不同的作法,第一個圖是用smarty,模式與以往無異,第二個圖是用cakephp。可以發現使用cakephp所載入的檔案和時間幾乎是多了一倍

可是就實際而言是否有差別?

我不能夠說完全沒有差別,可是至少在機器速度快的狀況下,差別應該不會大到哪去。對於很多公司而言,真正的問題是他們找不到好的方法維護他們的程式碼,而並不是買一台更快的Server。


更多閱讀
http://mk.netgenes.org/archives/230/
http://mk.netgenes.org/archives/217/
http://www.neo.com.tw/archives/000212.html
http://big5.pconline.com.cn/b5/www.pconline.com.cn/pcedu/empolder/wz/php/0404/349705.html


討論
不知道各位對php在MVC上的發展有啥看法呢?

我對php在MVC及Web Programming上再度掀起眾人的目光很有信心,
絕對不會只是RoR,企業的Java或.Net才有辦法。

zzlong:

kiwikiwi 兄的精闢見解,小弟領教了,我也有一些意見:
[list=1][*]編程語言無分平民/貴族,到了今天幾乎常用的語言都是 OOP,分別其實不大,所謂舉一反三,學懂了第一種,明白了一些基本的編成概念例如 object、encapsulation、inheritance 之類,跟著的第二、第三種語言也會很快上手。輕微的分別總會有的,PHP 對初學者來說比 Java 容易,是公認的事實,但是要寫一個像樣的應用程式(不是一個 Hello World 啦),兩者所花的時間差不多,因為功夫不在語法上,而是在系統的設計上。

[*]令人有印象 Java 適合大型的、企業專用的系統,PHP 則屬於個人用的、小型的應用程式,我認為原因有兩個:市場策略和開發架構。

Java 背後由 Sun 推動,聯合其他大型的科技公司推波助瀾,配合一大堆最流行的市場詞彙如可靠性、可信性、安全性、穩定性、跨平台等等,全方位地把大企業的領導洗腦,令他們相信優良的系統必定要用 Java 來開發。

PHP 多年來只有 Zend 一間公司在推動,其他的功夫大部分都是由志願性質的小組織來做,效果當然難與 Java 相比。

Java 一直以來不停推出各式各樣的架構和規範,初期主要由 Sun 推動,後來 Sun 組織社群 JCP 協助,對於開發大型系統有很大的意義。反觀 PHP 這方面的工作做得既零碎,又不統一,大家各行其是,不能給予開發大型專案的領導人足夠的信心,今天選了一個架構,誰知明天它是否還存在?

[*]載入時間的問題,倘若使用了 accelerator 的話其實問題不大,因為所有程式都只會載入一次。我反而對於 PHP 至今仍然沒有把 accelerator 的功能內置在系統中感到很奇怪(據說 PHP 6 將會這樣做),Java Servlet 在第一天推出的時候已經有這項功能。這裡再一次說明平民/貴族的分別並不在於語言本身,只要開發環境改善,青蛙也可變王子。[/list:o]

hoyo:

1. 系統的設計不在語法不在使用工具,只在於人上

2. 工具呈現的結果也不在主推的公司上,也在人上

3. 是否一定要開發環境完善才能青蛙變王子,結果也在人身上

kiwikiwi:


--- 引述: "zzlong" ---kiwikiwi 兄的精闢見解,小弟領教了,我也有一些意見:

[*]令人有印象 Java 適合大型的、企業專用的系統,PHP 則屬於個人用的、小型的應用程式,我認為原因有兩個:市場策略和開發架構。

Java 背後由 Sun 推動,聯合其他大型的科技公司推波助瀾,配合一大堆最流行的市場詞彙如可靠性、可信性、安全性、穩定性、跨平台等等,全方位地把大企業的領導洗腦,令他們相信優良的系統必定要用 Java 來開發。

PHP 多年來只有 Zend 一間公司在推動,其他的功夫大部分都是由志願性質的小組織來做,效果當然難與 Java 相比。

Java 一直以來不停推出各式各樣的架構和規範,初期主要由 Sun 推動,後來 Sun 組織社群 JCP 協助,對於開發大型系統有很大的意義。反觀 PHP 這方面的工作做得既零碎,又不統一,大家各行其是,不能給予開發大型專案的領導人足夠的信心,今天選了一個架構,誰知明天它是否還存在?


--- 引用結尾 ---


是啊,其實php的社群並沒有很大的向心力,造成各自發展獨特的技術。給新手或是不見得要選擇php方案的人來說,很容易就失去焦點或是不知所措。

相對於Java,.Net這樣子有相當明確的文件與平台,php真的要開發大型專案的話,不僅只是上網找方案,還得真的測試他能不能用。這對php而言是一種先天性的障礙,終究他是open source。但是也因為他是open source,儘管他不像Java,.Net整合度高,相對的好處就是擁有彈性。

說起來php有個優點就是可以很快速地改變web應用程式的架構,讓他會很相容現在的Web發展趨勢,因為這樣的特性,很多Web 2.0的應用程式前身,其推手就是php。反過來說雖然Java和.Net都有自己的Ajax Solution,我認為卻不足以代表他們能夠快速地適應Web程式設計的變化。如果php解決了他不適合開發大型專案的缺點,就表示說php的大型專案還是有可能創造出Java,.Net所做不到的。

這個影響的層次很大,因為未來的軟體主流應該是很多人可以用的Web軟體服務(這才賺錢!),而不是企業專用的客製化系統。


這是我的想法,很高興與你們討論 :)

hoyo:

php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!

頁: (1/5) > >>

前往完整版本