2006年6月23日 星期五

php與MVC

[b]有褒有貶[/b]

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

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



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

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

我想先談談php的優點。

[b]speed DOES matter[/b]

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

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

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

[b]MVC[/b]

此外有關於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裡的程式碼更多。參考這兩張圖:
[url=http://kiwi.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic1.PNG][img]http://kiwi.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic1.thumbnail.PNG[/img][/url][url=http://kiwi.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic2.PNG][img]http://kiwi.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic2.thumbnail.PNG[/img][/url]
我將同一個專案用不同的作法,第一個圖是用smarty,模式與以往無異,第二個圖是用cakephp。可以發現使用cakephp所載入的檔案和時間幾乎是多了一倍

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

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

[b]更多閱讀[/b]
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

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

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

5 則留言 :

  1. Dear kiwi,

    請教您一下,您那兩張圖片是用什麼軟體檢測出來的呢?
    謝謝!

    回覆刪除
  2. 這個是Zend Studio裡面附的Profiler :)

    回覆刪除
  3. Dear kiwi
    為什麼你會覺得java+struts的效能會無法負載很多人數呢?
    就我所知,struts只用了一個servlet去控制所有的動作
    加上developer經驗好的話,效能並不會比較差才對

    回覆刪除
  4. 直接斷言struts+jsp無法負載很多人數,這樣的斷言有點太過草率。能不能承受這樣的loading,開發者對於Struts的了解及Model使用也有關係。php常與mysql結合。mysql因為省去了ACID的實作。所以較Oracle有比較快的反應速度。對於企業資料庫的需求及特性,把DB當作Model層,對於效率與資料安全性是一件危險的事。
    在我看來php與java+struts是處理不同面向的問題。對於企業要求的是robust的架構與資料庫,或是系統間的整合,java+struts是比較好的選擇。

    php5對於OO的支援、smarty讓php MVC更加完整。不可否認,我也喜歡php的易上手,彈性,更喜歡有許多現成的open source的套件。較java+struts更適合web2.0或是一些想要有彈性,很炫的需求。

    舉個比較顯著的例子就是,會看到一個企業的宣傳網站,常是php。但是商業Portal常是java+struts

    回覆刪除
  5. 這個就如樓上這位說的是應用性的問題。我其實並不是說java+struts效能不好,但我覺得他能夠發揮的長處,就是系統整合。所以真的要走java路線的人一定會比較偏向用比較好的硬體來換取能跟後端商業邏輯高度整合的企業式應用程式這樣的價值,那種應用通常是重量級的。
    但是畢竟blog不是拿與後端系統整合當作目的吧?更何況學生要玩這種東西是沒有錢的。究竟哪一項會促進Web的發展呢?我覺得還是php寫出來的輕量級應用程式,而不是重量級的java。

    回覆刪除