作者 主題: php與MVC  (閱讀 61168 次)

0 會員 與 1 訪客 正在閱讀本文。

kiwikiwi

  • 可愛的小學生
  • *
  • 文章數: 11
    • 檢視個人資料
    • http://gridv6.csie.chu.edu.tw
php與MVC
« 於: 2006-06-23 15:48 »
有褒有貶

看到一些文章,真的是對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

  • 訪客
php與MVC
« 回覆 #1 於: 2006-06-27 11:20 »
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

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4053
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
php與MVC
« 回覆 #2 於: 2006-06-27 11:33 »
1. 系統的設計不在語法不在使用工具,只在於人上

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

3. 是否一定要開發環境完善才能青蛙變王子,結果也在人身上
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

kiwikiwi

  • 可愛的小學生
  • *
  • 文章數: 11
    • 檢視個人資料
    • http://gridv6.csie.chu.edu.tw
php與MVC
« 回覆 #3 於: 2006-06-27 13:45 »
引述: "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

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4053
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
php與MVC
« 回覆 #4 於: 2006-06-27 13:48 »
php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
php與MVC
« 回覆 #5 於: 2006-06-27 15:08 »
我想沒有所謂不適合大型專案上開發,而是在初期有沒有足夠的資源可以立刻幫助大型專案開發。

簡單的來說就是一個完整,且可靠能有效率擴充的Framework..

PHP 由於非常開放,所以導致很多有心人都可以建立自己的Framework,所以才會現在有這麼多不同的 Framework 在 php 上發展,我想也由於有這麼多種不同的Framework彼此競爭跟激勵,才會現在有這麼多優秀的架構跟元件可以使用。

至於適不適合開發大型專案,我覺得比較的重點應該還是在開發團隊,如何整合現有的資源。
例如目前許多入口網站,像是Yahoo,Pchome 等,基本上都是架構在 PHP 上,而 blog.yam.com 的日誌系統也是架構在 php 上,而他們使用了 phpmvc 這套老字號的 php framework .

至於最近有趣的 php framework ,我想 kiwikiwi 跟我一樣也有在注意的應該就是 cakephp 了,另外有個 symfony 也是非常優秀。

端看開發者的熟悉與使用囉。
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

kiwikiwi

  • 可愛的小學生
  • *
  • 文章數: 11
    • 檢視個人資料
    • http://gridv6.csie.chu.edu.tw
php與MVC
« 回覆 #6 於: 2006-06-27 16:32 »
引述: "hoyo"
php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!


我想上一篇的用詞可能會造成您的誤解。不能夠說是php的語言功能本身造成專案難以開發,而是早期php的設計師們大多都是用傳統的設計方式,也就是Java Struts裡提到的Model1來設計,造成顯示,程式邏輯,資料層的程式碼混雜。如果專案的程式碼,資料表相當多,維護人員的成本一定會大幅提昇。

至於說專案的大小如何區分?我想使用者的人數多寡,角色的多寡,系統功能的數量,資料表格的數量都可以是一個參考依據。就如同darkhero兄所言,其實或許不應該分做大小,主要當然還是看專案需求。不過目前的商業開發都是必須考慮成本,如果說想要縮短開發及維護的時間成本,不管專案大小,都要朝向良好的設計與規劃。

當然mvc的framework早早就有,只是我所看見許多小公司或工作室還是無法接受OOAD或是MVC的觀念,導致他們花很多時間在寫註解而不是在程式功能或設計架構上,甚為可惜。

hoyo

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4053
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
php與MVC
« 回覆 #7 於: 2006-06-27 16:42 »
引述: "kiwikiwi"
引述: "hoyo"
php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!


我想上一篇的用詞可能會造成您的誤解。不能夠說是php的語言功能本身造成專案難以開發,而是php的設計師們大多都是用傳統的設計方式,也就是Java Struts裡提到的Model1來設計,造成顯示,程式邏輯,資料層的程式碼混雜。如果專案的程式碼,資料表相當多,維護人員的成本一定會大幅提昇。

至於說專案的大小如何區分?我想使用者的人數多寡,角色的多寡,系統功能的數量,資料表格的數量都可以是一個參考依據。就如同darkhero兄所言,其實或許不應該分做大小,甚至說php4也可以寫出功能完善的系統,如xoops便是,但目前的商業開發都是必須考慮成本。如果說想要縮短開發及維護的時間成本,不管專案大小,都要朝向良好的設計與規劃。如果是採用MVC模式的話,就加上Framework的幫助,我相信這是未來的方向。


所以是人的問題,不是 php 的問題,對吧?

我只是不希望誤導到新手錯誤的觀念,因為有太多人對於 php 的能力感到懷疑,

我是不知道她們在懷疑什麼啦,至少我現在寫 MES 寫的很 HAPPY
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

zzlong

  • 訪客
php與MVC
« 回覆 #8 於: 2006-06-28 02:15 »
hoyo 兄說的是「可能性」的問題,PHP 是否可以用來編寫大型專案?他認為事在人為。這一點我同意,倘若我們只有 PHP 可以用,即使是登陸月球的專案也不得不用 PHP 來開發。

kiwikiwi 兄說的卻是現實的問題,現實是除了 PHP 外我們還有其他選擇,Java 在開發大型專案上的環境優勢前面已經說過,我不重複了,在考慮到成本效益、支援和風險時,PHP 便差得很遠了。

沒有搞清楚立場的爭論是沒有意義的。

說一個活生生的例子吧,我的公司有自己的 portal 系統,下半年我們將會改用 Oracle Portal,把所有自家開發特有功能用 Oracle portlet (相當於其他內容管理系統所謂的 module)重新實作,Oracle Portal 不便宜,用戶的數量更加與很多 PHP 的開源 CMS 系統少得多,但是它獲選的原因是:
[list=1]
  • 它是一個 Java 為本的系統
  • 它的背後有 Oracle 這個大靠山作出支援,全球 24 小時電話、電郵、online chat,PHP 哪一個 CMS 有這種服務?
  • 完善的手冊和教學文件,只是手冊便已經數百 MB,老闆當然不用看這些文件,他只是粗略掃描了一下文件的名稱和容量,便已經很滿意了
  • 完善的培訓課程,我的一個同事下星期便會公費到美國受訓一星期,我雖然很懷疑這種課程的實際作用,但無法否認對大公司的老闆來說,能夠提供這種課程的公司總有勝人一籌的感覺[/list:o]
    你們看,以上沒有一個因素跟技術有關,hoyo 兄估計會很失望,成事在人,只要有好的人才,甚麼語言、開發環境都不是障礙嘛,但是現實卻不是這樣的。

    還有一點我想澄清,就是 Sun 推動的不是 Java 開發架構(framework),而是架構規格(framework specification),架構的實作誰都可以做,但必須依照規格來進行,對應用系統的開發者來說,它的意義是今天選用 A 公司提供的數據庫抽象層實作,明天不滿意的話可以改用 B 公司的,應用程式一點也不用修改,因為介面已經被規格限制。

    現時大部分的架構規格都由 JCP 這個社區組織負責,成熟後 Sun 會把它放入 J2SE 或  J2EE 中,JCP 的成員很多都是專業而資深的技術人員,很多都是來自 IBM、Oracle 等大企業內的專家。

    PHP 在這方面的情況如何呢?

Darkhero

  • 酷!學園 學長們
  • 俺是博士!
  • *****
  • 文章數: 3728
  • 性別: 男
    • 檢視個人資料
    • ㄚ凱隨手紀
php與MVC
« 回覆 #9 於: 2006-06-28 08:25 »
我相信這就是Java的優點,讓其他公司有機會能建立相同介面的freamwork,因為他制定完全,且提供了非常完整的商業支援服務,舉凡教育訓練,或是文件等!

相對的我也相信 PHP 的優點在於他的多元性跟易用性,所以才讓各式各樣的想法與作法能在目前的網路上發光發熱!

至於 PHP 目前的話呢,個人並不認為 ZEND_framework 或是其他任何一個 Framework 有機會獨大,或是成為一個主流,但是多元的 Framework 相信也能讓更多人激勵出更優秀的作法。

而商業支援方面,ZEND 支援雖然還不錯,但是在於現成的 App 則不是很清除有什麼樣的支援。
目前一些主要的 CMS 或是 軟體專案 目前似乎還沒有看到那麼完整的支援。

---
這一串的討論真是非常有價值丫,我可以把他們置頂嗎?
希望我們的討論是為了把問題解決,而不是爭論誰對誰錯.
『灌水才是重點,發文只是順便』
『我寧可讓不會釣魚的工程師餓死,也不想讓會餓死的工程師去攪沉公司....』
Blog: http://blog.darkhero.net/
秘密基地: http://www.darkhero.net/comic/
目前服務的網站: http://www.libook.com.tw/

hoyo

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4053
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
php與MVC
« 回覆 #10 於: 2006-06-28 09:13 »
引述: "zzlong"
成事在人


所以你自己也再次說了,問題在於人,不在於工具......

工具是無辜的,php 是無辜的,php 萬歲~~~~~~

==========

本討論串最後一次發言 = =" (進瘋人院了)
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

hoyo

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4053
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
php與MVC
« 回覆 #11 於: 2006-06-28 09:17 »
引述: "zzlong"
Sun 推動的不是 Java 開發架構(framework),而是架構規格(framework specification),架構的實作誰都可以做,但必須依照規格來進行,對應用系統的開發者來說,它的意義是今天選用 A 公司提供的數據庫抽象層實作,明天不滿意的話可以改用 B 公司的,應用程式一點也不用修改,因為介面已經被規格限制。


非常認同,我相信這也是大家都使用 java, .net 來開發的原因,

因為在多人開發的環境,一致性的設計以及架構是重要的,php 比較起來“相對”弱勢。

===========

不要管我,我都自己寫,還沒和別人合作過,所以我是..... (請參考簽名檔)
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

zzlong

  • 訪客
php與MVC
« 回覆 #12 於: 2006-06-29 00:21 »
引述: "hoyo"
php 萬歲~~~~~~

我跟你一樣是 PHP 擁護者, 雖然我的工作以 Java 為本, 但是下班後我基本不想接觸它, Java 就像一個嚴肅的老頭, 睿智嚴謹卻沒有趣味, PHP 年輕活潑, 隨意而率性, 跟我很相似, 所以我工餘寫的程式全部用 PHP  :D  :D  :D

qrtt1

  • 懷疑的國中生
  • **
  • 文章數: 73
    • 檢視個人資料
php與MVC
« 回覆 #13 於: 2006-07-03 16:51 »
引述: "hoyo"
引述: "zzlong"
Sun 推動的不是 Java 開發架構(framework),而是架構規格(framework specification),架構的實作誰都可以做,但必須依照規格來進行,對應用系統的開發者來說,它的意義是今天選用 A 公司提供的數據庫抽象層實作,明天不滿意的話可以改用 B 公司的,應用程式一點也不用修改,因為介面已經被規格限制。


非常認同,我相信這也是大家都使用 java, .net 來開發的原因,

因為在多人開發的環境,一致性的設計以及架構是重要的,php 比較起來“相對”弱勢。

===========

不要管我,我都自己寫,還沒和別人合作過,所以我是..... (請參考簽名檔)


真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品

在用工具前, 還是先學學背後的理念吧

zzlong

  • 訪客
php與MVC
« 回覆 #14 於: 2006-07-03 23:31 »
引述: "qrtt1"
真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品

有甚麼奇怪?MVC 是語言中性的,Java 跟 MVC 沒有必然關係,寫 Java 的人為甚麼不可以懷疑 MVC?

退一萬步來說,即使寫 Java 的人懷疑 OOP 也不需奇怪,看到不足才會尋求改進,懂得懷疑的人通常都是敢於突破的人,科技就是靠這樣發展下去的。

抱持懷疑的態度本身沒有問題,要注意的應該是懷疑的內容、理據、論點等是否合理和有建設性,不知那些人懷疑甚麼呢?你對那些懷疑有甚麼看法呢?

引述: "qrtt1"
在用工具前, 還是先學學背後的理念吧

在這個主題發言的人,除了小弟之外,應該都不是人云亦云之輩,對各種編程語言,尤其是 PHP,都有相當的經驗,對各種開發技術、架構、工具、規劃等東西都有深刻的了解,我看你似乎找錯了對象。

qrtt1

  • 懷疑的國中生
  • **
  • 文章數: 73
    • 檢視個人資料
php與MVC
« 回覆 #15 於: 2006-07-04 21:59 »
引述: "zzlong"
引述: "qrtt1"
真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品

有甚麼奇怪?MVC 是語言中性的,Java 跟 MVC 沒有必然關係,寫 Java 的人為甚麼不可以懷疑 MVC?

退一萬步來說,即使寫 Java 的人懷疑 OOP 也不需奇怪,看到不足才會尋求改進,懂得懷疑的人通常都是敢於突破的人,科技就是靠這樣發展下去的。

抱持懷疑的態度本身沒有問題,要注意的應該是懷疑的內容、理據、論點等是否合理和有建設性,不知那些人懷疑甚麼呢?你對那些懷疑有甚麼看法呢?

引述: "qrtt1"
在用工具前, 還是先學學背後的理念吧

在這個主題發言的人,除了小弟之外,應該都不是人云亦云之輩,對各種編程語言,尤其是 PHP,都有相當的經驗,對各種開發技術、架構、工具、規劃等東西都有深刻的了解,我看你似乎找錯了對象。


針對別人的懷疑沒什麼特別的看法, 請把我當成人云亦云之輩即可:)
打混了一些時間也看了一二樣工具,
不過也許是時代進步太快,趕流行的人太多。
也有人見一個換一個,也有人學了一種就巴著不放

至於我,好像沒什麼主見>"< 有時想換,有時想堅持到底。
最近心理的聲音是"要怎麼把ooo發揮到100%呢?
ooo可以代換為任意工具都無所謂orz

FIEND

  • 鑽研的研究生
  • *****
  • 文章數: 700
    • 檢視個人資料
    • http://bbs.ecstart.com
php與MVC
« 回覆 #16 於: 2006-07-08 22:24 »
看完大家的心得 . 其實小弟蠻推崇 hoyo 大哥的說法的 .

而且小弟也不覺得跟語言有關係而是跟人有關係 .

小弟也報告一下個人一點點小小的心得 :

小弟覺得 mvc 其實只是個名詞  會因為 工程師的經驗産生不同的想法 .

設計出來的模組 差異化也很大 . 或許 讓 資深點的 programer 去設計 整個架構 .

會比較容易發揮 mvc 的精神 .

而且經驗這種東西也不是三言二語可以說明白的 .

有的工程師 寫個功能只要十分鐘 有的工程師寫個功能 要 一星期.

差別在 有的工程師 會花心思在 程式的 延展性和彈性上讓程式的重覆使用性及彈性發揮到最大.

有的工程師解個 bug 只要 花五分鐘  , 同樣的東西有的人確要解 上一整天  .

有的工程師則是看到什麼寫什麼 .

一樣都用 mvc 的楖念去寫可是差異就很大 .  

例如

1. .net asp 小弟覺得 設計的很差 , 可是確很直覺拉一拉東西就出來了 但是 要速度快要好  

    維護 還不是挺好 它將 版型和 程式的邏輯偷偷做掉強迫 使用者會用它的模組就好 , 這
   
    樣 對 程設師來說 細微的問題 真的蠻難掌 握的 不過如果覺得它的 模組夠用 那還ok 算

    是蠻好的工具.

2. smarty 它可以分離 程式和版型 但是 實際上 對多層架構有常識的 工程師 會將

    php 邏輯 與 smarty 版型遇輯要做的事分清礎 因為 smarty 可以下版型邏輯 .
   
    版型上的事就交給 smarty 做 不要給 php 做 才可以讓程式富有延展性和一致性 開發的

    速度才會又快又好維護

3. XML + XSL 它的功能同 smarty 不過它 的 版型邏輯 是標準化的 可以跨平台誇程式語言

    也就是 只要吐出來的xml 一致 xsl 就會將 畫面給處理出來 .

結何上述的想法 , 後來 小弟 最近幾年 慢慢對自己開發的環境 設計出一些 適合自己用的開發元件 ,

初期 的想法 是

好煩 每次 新增都要 對 資料庫 所以我 寫了一個 function 只要 給參數就會 新增 且跳回指定的網頁 .

好煩 每次 刪除都要 對 資料庫 所以我 寫了一個 function 只要 給參數就會 新增 且跳回指定的網頁 .

好煩 每次 拉 換頁的 record 時都要 對 半 天 所以又寫了一支 專叫 record 的 function

每次處理換頁 都要重新拉一次 用 call function  吧 .

結果整理出 :

一個 完整的功能不外乎是

新增  修改 刪除 record search sort sitemap  relation ..............

結果全都寫了一個 function , 這時 smarty 或 xml 就有用處了

因為它可以讓 php 邏輯 和 版型邏輯有一玫性和延展性 .

所以  新增  修改 刪除 record search sort sitemap  relation .............. 吐 出來的資料 讓它的格式都一樣  .

ok 這樣一來 所有叫用 content layer 的程式我都不用寫了  只要 給參數它就會 幫我 叫出來

我也不用考慮 bug 或 測試的問題了 .. 節省  1/10 的時間了 .

所以我的程式是長這樣的 ^^!! 我徒弟 第一次看到時 坐在 電腦前發呆蠻久的 不過教一教 一下子就會用了

再來 這些東西我幾乎都不自己寫 而且這些東西也會強迫底下的人沒法子寫出一些恐龍程式出來  :

代碼: [選擇]

<?php
$max_page       
10 ;
$max_range      10 ;
$table_name     "fun" ;
$default_sort   " order by seq asc" ;
$search_str "
                &#58; and &#58; pjid            &#58;       =                       ,
                &#58; and &#58; id              &#58;       like    &#58;%      &#58;%      ,
                &#58; and &#58; name            &#58;       like    &#58;%      &#58;%      ,
                &#58; and &#58; node            &#58;       =                       ,
                &#58; and &#58; layer           &#58;       =                       ,
                &#58; and &#58; link            &#58;       =                       ,
                &#58; and &#58; descript        &#58;       like    &#58;%      &#58;%      ,
                &#58; and &#58; message         &#58;       like    &#58;%      &#58;%      ,
                &#58; and &#58; open            &#58;       =
;
$sort_str "
                &#58; pjid          ,
                &#58; id            ,
                &#58; name          ,
                &#58; node          ,
                &#58; layer         ,
                &#58; link          ,
                &#58; seq           ,
                &#58; descript      ,
                &#58; message       ,
                &#58; open          ,
                &#58; idatetime     ,
                &#58; sdatetime
"
;
$relation_str "
                project &#58; id &#58; name
"
;


$insert_str =   "
                pjid,
                id,
                name,
                node,
                layer,
                link,
                seq,
                descript,
                message,
                open,
                idatetime
"
;

$update_id =   "
                id
"
;
$update_str =   "
                pjid,
                id,
                name,
                node,
                layer,
                link,
                seq,
                descript,
                message,
                open,
                idatetime
"
;


?>




再來是版型 同理 , 我發現 page relation sort ........ 去吃資料的邏 輯也有一定的rule

好吧 那我 也設計出幾個 block  要用時 直接把 block 指向 吐出來的資料就好了 .

............. 結果 一個功 能 :

新增  , 修改 , 刪除 , 排序 ,  record list , 換頁 , sitemap . 老實說  不用十分鐘就可以寫好了 .

節省大量的開發時間再來花 個二十分 檢查一下 .

開發專案時  , 設計 一個 八十個 table 的 專案 大楖 設計花了  一二個星期  , 可是寫的話 只要 四五天左右 而且還不用很趕 一天寫十六個功能 也就是半小時 寫一個 可是其實參數填進去 版型參數填進去  只要花十分 鐘 還有二十分在 聊天打屁  .

這意味著 只要 sa 夠力 , 設計出來的東西一次 ok 底下多找幾個 coding 的人

用 設計好的模組狂抄 生產力 是很可怕的 , 也許一個月就是其它公司 一整年的產能以上 .

再來是測試除錯  大楖要花 一二個星期 ,.


小弟發現 也就是說在 這個軟體愈來愈進步的年代 , 以前的開發習慣 及語言的限制 .

就好像是 家庭手工或是手工藝品 一樣一件件 慢慢的做出來 .

而 目前的工具發達到  則是 像工業時代一樣 生產速度 是以往的幾十倍幾百偣 .

資深的工程師就像廠長一樣 接到訂單 塑模 開模 訂生產線 準備大量生產 .

資淺的工程師就像 工廠的作業員 .

而模組就是機器 不停的把材料打出來給 作業員去 包裝 ....  生態好像變成這樣了  ^^!!


一個 良好的架構讓 開發程式變的輕鬆好玩又快速又有效率 , 真的事在人為 .

也許大家不要再把心思放在 語法和流程 把時間放在 設計上 會覺得程式設計是一個蠻好玩東西 .
你累了嗎? 這樣不行 , 人要比 LINUX 兇 @@ " ......

shengeih

  • 鑽研的研究生
  • *****
  • 文章數: 970
    • 檢視個人資料
php與MVC
« 回覆 #17 於: 2006-12-04 10:03 »
FIEND 的概念真是不錯,了解懂得運用 funciton.
目前我也是針對用 php 來開發中大型的案子.雖然我用的是 Xtempalte .

不過也用的很高興就是了.

axisqq

  • 可愛的小學生
  • *
  • 文章數: 3
    • 檢視個人資料
php與MVC
« 回覆 #18 於: 2007-09-11 16:25 »
不好意思吐個嘈
樓上那位FIEND大大所寫的function

代碼: [選擇]
$search_str = "
                : and : pjid            :       =                       ,
                : and : id              :       like    :%      :%      ,
                : and : name            :       like    :%      :%      ,
                : and : node            :       =                       ,
                : and : layer           :       =                       ,
                : and : link            :       =                       ,
                : and : descript        :       like    :%      :%      ,
                : and : message         :       like    :%      :%      ,
                : and : open            :       =
" ;


小弟才疏學淺,請問這是SQL語法嗎???

另外專為某個專案所設計的class,要完全不用修改

就套用到另一個專案上用,除非這兩個專案內容和結構相似度99%

尤其是你的sql語法(如果那個是「標準」的sql語法的話)裡還包含

該專案的資料庫欄位名稱,那這個class要套到另一個專案上

除非兩者的資料庫結構一樣  不然的話非大改不可  花得時間更多

axisqq

  • 可愛的小學生
  • *
  • 文章數: 3
    • 檢視個人資料
php與MVC
« 回覆 #19 於: 2007-09-11 16:36 »
做個比喻吧...

我覺得PHP  V.S  ASP,JSP.....

就好比

AK47  V.S  M4A1

FIREFOX   V.S   MS.IE

自由軟體    V.S   商業軟體

平民   V.S   大企業

散戶   V.S   法人

人民力量    V.S    國家權力

PHP,窮人的原子彈

fillano

  • 鑽研的研究生
  • *****
  • 文章數: 526
    • 檢視個人資料
php與MVC
« 回覆 #20 於: 2007-09-11 17:42 »
引述: "axisqq"

.......

小弟才疏學淺,請問這是SQL語法嗎???

另外專為某個專案所設計的class,要完全不用修改

就套用到另一個專案上用,除非這兩個專案內容和結構相似度99%

尤其是你的sql語法(如果那個是「標準」的sql語法的話)裡還包含

該專案的資料庫欄位名稱,那這個class要套到另一個專案上

除非兩者的資料庫結構一樣  不然的話非大改不可  花得時間更多


他的想法類似ORM,是可以做快速開發的。資料關係其實在設計資料庫的時候就決定了,把這些關係跟存取資料的方法都作成函數,就可以快速hanle資料。

view層是由smarty控制的話,只要寫好餵資料的函數,在模板加上資料呈現邏輯就可以了。

最後,開發工作只是做出的程式邏輯(流程等等),其他事情只要簡單呼叫幾個函數就可以搞定。

其實進一步可以利用設計資料庫的時候自動產生他設計的這些字串,這樣時間就更省了。

大概是這樣吧?cake也就是這樣做的。
Sapere aude! Habe Mut, dich deines eigenen Verstandes zu bedienen! ist also der Wahlspruch der Aufklärung.

FIEND

  • 鑽研的研究生
  • *****
  • 文章數: 700
    • 檢視個人資料
    • http://bbs.ecstart.com
回覆: php與MVC
« 回覆 #21 於: 2009-06-23 11:56 »
@@" 那篇文章好多年了 噗~~

而且 那個 下參數的方法大楖是小弟五年前的作品吧 ^^....

謝謝 fillano 的補充 ..

cake php 的 model layer 確實規畫的不錯...

不過我蠻厭惡 它將 畫面邏輯放到內容邏輯 或是把 內容邏輯放到畫面邏輯 這件事.

@@ 就好像一個大美女 臉上長了一個大痔一樣... 噗~~


##


另外 我蠻推薦用這套來學習怎麼規畫 model layer 的...

http://www.sqlalchemy.org/

我目前用的php產品開發框架 也是 學習  sqlalchemy 的規畫 ^^.

本來我想用 python 拉db 吐 xml 然後 跟 php 接在一起... 呵呵...

可惜 python 的 http 上的 i/o 遠比 php 弱太多太多了... 所以放棄回頭用 php ccc..


« 上次編輯: 2009-06-23 12:11 由 FIEND »
你累了嗎? 這樣不行 , 人要比 LINUX 兇 @@ " ......

bill80362

  • 懷疑的國中生
  • **
  • 文章數: 38
    • 檢視個人資料
回覆: php與MVC
« 回覆 #22 於: 2009-07-23 17:02 »
PHP 只有市場才能決定
我們只能猜測囉~
猜的出來~就可以去買股票哩~~

loveyou

  • 可愛的小學生
  • *
  • 文章數: 3
    • 檢視個人資料
回覆: php與MVC
« 回覆 #23 於: 2010-01-22 17:29 »
其實這也要看個人的喜好了 :)
永捷小客車:包車、租車、機場接送
哈比咖啡:咖啡豆,咖啡豆專賣店,莊園咖啡豆,咖啡豆宅配,咖啡機,咖啡豆烘焙,咖啡工具,咖啡禮盒,咖啡生豆,掛耳式咖啡,咖啡豆批發。
凌廣工業股份有限公司: Powder blender,Ribbon mixer,Pulverizer,Hammer mill,Grinding mill
八方國際翻譯:口譯,筆譯,翻譯,翻譯社,翻譯公司
中華資產鑑定中心股份有限公司:中華不動產,不動產鑑定,資產鑑價,估價鑑價 ,鑑價公司,鑑價估價 ,動產估價-機器,中華資產鑑定-不動產鑑價 ,不動產估價師,不動產估價,估價師,無形資產評估,不動產估價師事務所

jackmr

  • 可愛的小學生
  • *
  • 文章數: 11
    • 檢視個人資料
    • 數碼維基
Re: php與MVC
« 回覆 #24 於: 2015-03-16 04:29 »
樓上的打廣告也太明顯.

這幾年 PHP 的 MVC Framework 已經很成熟了

但不想套用大的框架搞得每次載入一堆東西讀一頁就耗一堆記憶題
所以我現在都用 codeigniter 簡單好用
怎麼玩最多讀一頁只耗 2.5MB 以下我覺得還不錯
hi all !