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

php與MVC

<< < (2/5) > >>

Darkhero:
我想沒有所謂不適合大型專案上開發,而是在初期有沒有足夠的資源可以立刻幫助大型專案開發。

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

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

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

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

端看開發者的熟悉與使用囉。

kiwikiwi:

--- 引述: "hoyo" ---php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!
--- 引用結尾 ---


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

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

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

hoyo:

--- 引述: "kiwikiwi" ---
--- 引述: "hoyo" ---php 如何不適合在大型專案上開發?又多大才稱為大型專案?

請指教,謝謝!
--- 引用結尾 ---


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

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


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

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

我是不知道她們在懷疑什麼啦,至少我現在寫 MES 寫的很 HAPPY

zzlong:
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:
我相信這就是Java的優點,讓其他公司有機會能建立相同介面的freamwork,因為他制定完全,且提供了非常完整的商業支援服務,舉凡教育訓練,或是文件等!

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

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

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

---
這一串的討論真是非常有價值丫,我可以把他們置頂嗎?

導覽

[0] 文章列表

[#] 下頁

[*] 上頁

前往完整版本