酷!學園
技術討論區 => 程式討論版 => PHP程式設計討論區 => 主題作者是: kiwikiwi 於 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裡的程式碼更多。參考這兩張圖:
(http://gridv6.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic1.thumbnail.PNG) (http://gridv6.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic1.PNG)(http://gridv6.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic2.thumbnail.PNG) (http://gridv6.csie.chu.edu.tw/blog/wp-content/uploads/2006/06/pic2.PNG)
我將同一個專案用不同的作法,第一個圖是用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才有辦法。
-
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]
-
1. 系統的設計不在語法不在使用工具,只在於人上
2. 工具呈現的結果也不在主推的公司上,也在人上
3. 是否一定要開發環境完善才能青蛙變王子,結果也在人身上
-
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軟體服務(這才賺錢!),而不是企業專用的客製化系統。
這是我的想法,很高興與你們討論 :)
-
php 如何不適合在大型專案上開發?又多大才稱為大型專案?
請指教,謝謝!
-
我想沒有所謂不適合大型專案上開發,而是在初期有沒有足夠的資源可以立刻幫助大型專案開發。
簡單的來說就是一個完整,且可靠能有效率擴充的Framework..
PHP 由於非常開放,所以導致很多有心人都可以建立自己的Framework,所以才會現在有這麼多不同的 Framework 在 php 上發展,我想也由於有這麼多種不同的Framework彼此競爭跟激勵,才會現在有這麼多優秀的架構跟元件可以使用。
至於適不適合開發大型專案,我覺得比較的重點應該還是在開發團隊,如何整合現有的資源。
例如目前許多入口網站,像是Yahoo,Pchome 等,基本上都是架構在 PHP 上,而 blog.yam.com 的日誌系統也是架構在 php 上,而他們使用了 phpmvc 這套老字號的 php framework .
至於最近有趣的 php framework ,我想 kiwikiwi 跟我一樣也有在注意的應該就是 cakephp 了,另外有個 symfony 也是非常優秀。
端看開發者的熟悉與使用囉。
-
php 如何不適合在大型專案上開發?又多大才稱為大型專案?
請指教,謝謝!
我想上一篇的用詞可能會造成您的誤解。不能夠說是php的語言功能本身造成專案難以開發,而是早期php的設計師們大多都是用傳統的設計方式,也就是Java Struts裡提到的Model1來設計,造成顯示,程式邏輯,資料層的程式碼混雜。如果專案的程式碼,資料表相當多,維護人員的成本一定會大幅提昇。
至於說專案的大小如何區分?我想使用者的人數多寡,角色的多寡,系統功能的數量,資料表格的數量都可以是一個參考依據。就如同darkhero兄所言,其實或許不應該分做大小,主要當然還是看專案需求。不過目前的商業開發都是必須考慮成本,如果說想要縮短開發及維護的時間成本,不管專案大小,都要朝向良好的設計與規劃。
當然mvc的framework早早就有,只是我所看見許多小公司或工作室還是無法接受OOAD或是MVC的觀念,導致他們花很多時間在寫註解而不是在程式功能或設計架構上,甚為可惜。
-
php 如何不適合在大型專案上開發?又多大才稱為大型專案?
請指教,謝謝!
我想上一篇的用詞可能會造成您的誤解。不能夠說是php的語言功能本身造成專案難以開發,而是php的設計師們大多都是用傳統的設計方式,也就是Java Struts裡提到的Model1來設計,造成顯示,程式邏輯,資料層的程式碼混雜。如果專案的程式碼,資料表相當多,維護人員的成本一定會大幅提昇。
至於說專案的大小如何區分?我想使用者的人數多寡,角色的多寡,系統功能的數量,資料表格的數量都可以是一個參考依據。就如同darkhero兄所言,其實或許不應該分做大小,甚至說php4也可以寫出功能完善的系統,如xoops便是,但目前的商業開發都是必須考慮成本。如果說想要縮短開發及維護的時間成本,不管專案大小,都要朝向良好的設計與規劃。如果是採用MVC模式的話,就加上Framework的幫助,我相信這是未來的方向。
所以是人的問題,不是 php 的問題,對吧?
我只是不希望誤導到新手錯誤的觀念,因為有太多人對於 php 的能力感到懷疑,
我是不知道她們在懷疑什麼啦,至少我現在寫 MES 寫的很 HAPPY
-
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 在這方面的情況如何呢?
-
我相信這就是Java的優點,讓其他公司有機會能建立相同介面的freamwork,因為他制定完全,且提供了非常完整的商業支援服務,舉凡教育訓練,或是文件等!
相對的我也相信 PHP 的優點在於他的多元性跟易用性,所以才讓各式各樣的想法與作法能在目前的網路上發光發熱!
至於 PHP 目前的話呢,個人並不認為 ZEND_framework 或是其他任何一個 Framework 有機會獨大,或是成為一個主流,但是多元的 Framework 相信也能讓更多人激勵出更優秀的作法。
而商業支援方面,ZEND 支援雖然還不錯,但是在於現成的 App 則不是很清除有什麼樣的支援。
目前一些主要的 CMS 或是 軟體專案 目前似乎還沒有看到那麼完整的支援。
---
這一串的討論真是非常有價值丫,我可以把他們置頂嗎?
-
成事在人
所以你自己也再次說了,問題在於人,不在於工具......
工具是無辜的,php 是無辜的,php 萬歲~~~~~~
==========
本討論串最後一次發言 = =" (進瘋人院了)
-
Sun 推動的不是 Java 開發架構(framework),而是架構規格(framework specification),架構的實作誰都可以做,但必須依照規格來進行,對應用系統的開發者來說,它的意義是今天選用 A 公司提供的數據庫抽象層實作,明天不滿意的話可以改用 B 公司的,應用程式一點也不用修改,因為介面已經被規格限制。
非常認同,我相信這也是大家都使用 java, .net 來開發的原因,
因為在多人開發的環境,一致性的設計以及架構是重要的,php 比較起來“相對”弱勢。
===========
不要管我,我都自己寫,還沒和別人合作過,所以我是..... (請參考簽名檔)
-
php 萬歲~~~~~~
我跟你一樣是 PHP 擁護者, 雖然我的工作以 Java 為本, 但是下班後我基本不想接觸它, Java 就像一個嚴肅的老頭, 睿智嚴謹卻沒有趣味, PHP 年輕活潑, 隨意而率性, 跟我很相似, 所以我工餘寫的程式全部用 PHP :D :D :D
-
Sun 推動的不是 Java 開發架構(framework),而是架構規格(framework specification),架構的實作誰都可以做,但必須依照規格來進行,對應用系統的開發者來說,它的意義是今天選用 A 公司提供的數據庫抽象層實作,明天不滿意的話可以改用 B 公司的,應用程式一點也不用修改,因為介面已經被規格限制。
非常認同,我相信這也是大家都使用 java, .net 來開發的原因,
因為在多人開發的環境,一致性的設計以及架構是重要的,php 比較起來“相對”弱勢。
===========
不要管我,我都自己寫,還沒和別人合作過,所以我是..... (請參考簽名檔)
真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品
在用工具前, 還是先學學背後的理念吧
-
真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品
有甚麼奇怪?MVC 是語言中性的,Java 跟 MVC 沒有必然關係,寫 Java 的人為甚麼不可以懷疑 MVC?
退一萬步來說,即使寫 Java 的人懷疑 OOP 也不需奇怪,看到不足才會尋求改進,懂得懷疑的人通常都是敢於突破的人,科技就是靠這樣發展下去的。
抱持懷疑的態度本身沒有問題,要注意的應該是懷疑的內容、理據、論點等是否合理和有建設性,不知那些人懷疑甚麼呢?你對那些懷疑有甚麼看法呢?
在用工具前, 還是先學學背後的理念吧
在這個主題發言的人,除了小弟之外,應該都不是人云亦云之輩,對各種編程語言,尤其是 PHP,都有相當的經驗,對各種開發技術、架構、工具、規劃等東西都有深刻的了解,我看你似乎找錯了對象。
-
真是怪了@"@
在java版都看人說java的mvc不好用
在php版卻看人懷疑php....
說到底有人把mvc寫的很不彈性
也有人把mvc寫的很像藝術品
有甚麼奇怪?MVC 是語言中性的,Java 跟 MVC 沒有必然關係,寫 Java 的人為甚麼不可以懷疑 MVC?
退一萬步來說,即使寫 Java 的人懷疑 OOP 也不需奇怪,看到不足才會尋求改進,懂得懷疑的人通常都是敢於突破的人,科技就是靠這樣發展下去的。
抱持懷疑的態度本身沒有問題,要注意的應該是懷疑的內容、理據、論點等是否合理和有建設性,不知那些人懷疑甚麼呢?你對那些懷疑有甚麼看法呢?
在用工具前, 還是先學學背後的理念吧
在這個主題發言的人,除了小弟之外,應該都不是人云亦云之輩,對各種編程語言,尤其是 PHP,都有相當的經驗,對各種開發技術、架構、工具、規劃等東西都有深刻的了解,我看你似乎找錯了對象。
針對別人的懷疑沒什麼特別的看法, 請把我當成人云亦云之輩即可:)
打混了一些時間也看了一二樣工具,
不過也許是時代進步太快,趕流行的人太多。
也有人見一個換一個,也有人學了一種就巴著不放
至於我,好像沒什麼主見>"< 有時想換,有時想堅持到底。
最近心理的聲音是"要怎麼把ooo發揮到100%呢?
ooo可以代換為任意工具都無所謂orz
-
看完大家的心得 . 其實小弟蠻推崇 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 = "
: and : pjid : = ,
: and : id : like :% :% ,
: and : name : like :% :% ,
: and : node : = ,
: and : layer : = ,
: and : link : = ,
: and : descript : like :% :% ,
: and : message : like :% :% ,
: and : open : =
" ;
$sort_str = "
: pjid ,
: id ,
: name ,
: node ,
: layer ,
: link ,
: seq ,
: descript ,
: message ,
: open ,
: idatetime ,
: sdatetime
";
$relation_str = "
project : id : 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 的人
用 設計好的模組狂抄 生產力 是很可怕的 , 也許一個月就是其它公司 一整年的產能以上 .
再來是測試除錯 大楖要花 一二個星期 ,.
小弟發現 也就是說在 這個軟體愈來愈進步的年代 , 以前的開發習慣 及語言的限制 .
就好像是 家庭手工或是手工藝品 一樣一件件 慢慢的做出來 .
而 目前的工具發達到 則是 像工業時代一樣 生產速度 是以往的幾十倍幾百偣 .
資深的工程師就像廠長一樣 接到訂單 塑模 開模 訂生產線 準備大量生產 .
資淺的工程師就像 工廠的作業員 .
而模組就是機器 不停的把材料打出來給 作業員去 包裝 .... 生態好像變成這樣了 ^^!!
一個 良好的架構讓 開發程式變的輕鬆好玩又快速又有效率 , 真的事在人為 .
也許大家不要再把心思放在 語法和流程 把時間放在 設計上 會覺得程式設計是一個蠻好玩東西 .
-
FIEND 的概念真是不錯,了解懂得運用 funciton.
目前我也是針對用 php 來開發中大型的案子.雖然我用的是 Xtempalte .
不過也用的很高興就是了.
-
不好意思吐個嘈
樓上那位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要套到另一個專案上
除非兩者的資料庫結構一樣 不然的話非大改不可 花得時間更多
-
做個比喻吧...
我覺得PHP V.S ASP,JSP.....
就好比
AK47 V.S M4A1
FIREFOX V.S MS.IE
自由軟體 V.S 商業軟體
平民 V.S 大企業
散戶 V.S 法人
人民力量 V.S 國家權力
PHP,窮人的原子彈
-
.......
小弟才疏學淺,請問這是SQL語法嗎???
另外專為某個專案所設計的class,要完全不用修改
就套用到另一個專案上用,除非這兩個專案內容和結構相似度99%
尤其是你的sql語法(如果那個是「標準」的sql語法的話)裡還包含
該專案的資料庫欄位名稱,那這個class要套到另一個專案上
除非兩者的資料庫結構一樣 不然的話非大改不可 花得時間更多
他的想法類似ORM,是可以做快速開發的。資料關係其實在設計資料庫的時候就決定了,把這些關係跟存取資料的方法都作成函數,就可以快速hanle資料。
view層是由smarty控制的話,只要寫好餵資料的函數,在模板加上資料呈現邏輯就可以了。
最後,開發工作只是做出的程式邏輯(流程等等),其他事情只要簡單呼叫幾個函數就可以搞定。
其實進一步可以利用設計資料庫的時候自動產生他設計的這些字串,這樣時間就更省了。
大概是這樣吧?cake也就是這樣做的。
-
@@" 那篇文章好多年了 噗~~
而且 那個 下參數的方法大楖是小弟五年前的作品吧 ^^....
謝謝 fillano 的補充 ..
cake php 的 model layer 確實規畫的不錯...
不過我蠻厭惡 它將 畫面邏輯放到內容邏輯 或是把 內容邏輯放到畫面邏輯 這件事.
@@ 就好像一個大美女 臉上長了一個大痔一樣... 噗~~
##
另外 我蠻推薦用這套來學習怎麼規畫 model layer 的...
http://www.sqlalchemy.org/
我目前用的php產品開發框架 也是 學習 sqlalchemy 的規畫 ^^.
本來我想用 python 拉db 吐 xml 然後 跟 php 接在一起... 呵呵...
可惜 python 的 http 上的 i/o 遠比 php 弱太多太多了... 所以放棄回頭用 php ccc..
-
PHP 只有市場才能決定
我們只能猜測囉~
猜的出來~就可以去買股票哩~~
-
其實這也要看個人的喜好了 :)
-
樓上的打廣告也太明顯.
這幾年 PHP 的 MVC Framework 已經很成熟了
但不想套用大的框架搞得每次載入一堆東西讀一頁就耗一堆記憶題
所以我現在都用 codeigniter 簡單好用
怎麼玩最多讀一頁只耗 2.5MB 以下我覺得還不錯