為什麼大部份開源項目不用MVC架構開發?

來源:互聯網
上載者:User
主流的PHP開源應用如:Discuz,WordPress,各種cms等
基本上都沒有使用開源架構開發。

除了曆史原因以外:
1、如果使用架構開發是不是更加安全成熟穩定?
2、有哪些因素導致這些開源項目不採用開源的MVC架構
3、使用開源MVC架構有哪些弊端?

回複內容:

朋友你好,謝邀。希望我的理解對你的協助大於誤導。接著說說我的看法。

通過題目看出題主對PHP很有感覺哦。我個人雖然不是一個專業的phper,當初確也學過並且真的實踐過。感覺php確實是逆襲的利器,成本低開發快,而且效能都還不錯。額,跑題了,咱們今天不是討論語言,而是應該轉到開源、架構、mvc等話題上。

首先說說樓主的題目,我不知道你是怎麼理解mvc的。mvc是一種設計思想,是一種設計模式。這個應該沒錯,但是任何一個架構的賣點絕不是因為他是遵循mvc模式開發的。而是因為它實打實的提供某類問題的快速解決方案。你使用它是因為你有這樣的需求它能給你帶來便利。但凡某個mvc架構的介紹基本都是這樣的,xx是一個用來解決xx問題的mvc架構,你應該可以看出,重點是能解決什麼,而不是後面附帶的mvc架構。架構就好比給程式員使用的產品,一個產品如果不是針對某類具體問題而生的,那麼這個產品的意義就不好說了。如果你僅把mvc當做一個產品,那麼就好比你的產品什麼都能做,但是什麼都做不好,誰都不需要這類產品。

我想我剛才繞遠了,其實我只是想說我們選擇一個架構往往取決於該架構的開發目的,而不是開發模式。

說起架構我立馬就想起了java的ssh架構。好似成了java本身的一部分一樣。現在學過java的人,一般都會接著去學習ssh架構。而且ssh使用率也非常高。想起了以前讀書時那段在圖書館啃著java大塊頭書籍的時光了。哎,往事不堪回首啊。好了,趕緊轉入正題。

接下來說說引入一個架構可能產生的問題:
  • 效能損失。但凡架構都會帶來效能損失,這也是一些對效能要求很高的項目往往不會使用架構,而為自己的情境定製最佳化。當然這個效能在如今來說大概也可以忽略了。
  • 複雜度提升。學習成本和部署成本這就是你必然要面對的問題。
  • 適應性。架構一旦引入,你的整體結構就被固定死了,你需要按照固定的模式去使用,這個地方加一些自己寫的具體代碼,另外一個地方加一點,這些都是架構幫你規定好了的。這東西可能其實也挺好,方面你後續維護什麼的,但是你得去適應。
  • 摩擦。這個東西就不好說了,有些架構有些地方可能非常符合你的需求,有些地方卻不是你想要的,甚至是反向的。這個時候你要麼就去hack一下,要麼就去修改一下該架構的原始碼。總之你使用起來不會特別爽。
說了架構說說php語言本身。作為一門易學習使用,大量函數內建的這麼一門語言。你發現你很多操作都不需要自己封裝實現,內建的都已經足夠強大了。以前在深受mvc熏陶下,我用php寫東西會這樣,首先建立module,view,server3個目錄,然後按照這種思路去填充對應的代碼。這算不算一種mvc的簡易實現了?所以個人覺得php內建的強大可能導致更少的使用架構。一個架構不能過於抽象,也不能太具化。對php來說這點就很難把握。有時候你應該想想你需要的是一些php程式碼片段還是一個架構。

Discuz,WordPress等這些東西為什麼不使用開源架構?我也想嘗試著回答。但是只是揣測而已。
這些東西往往職責單一,目標明確,而且使用php開發,其代碼量也不一定非常多。使用架構一來難以靈活適應情境需求,而來其帶來了更高的複雜度。這類福士類產品,大部分使用者需要的是快速安裝使用,少部分程式員希望修改自訂。所以不管出於何種需求,複雜總不是個好東西。還有可能的原因就是作者看不上別人的代碼。自己怎麼寫怎麼爽。開原始碼往往追求自由,而商業項目往往追求效率。所以商業項目往往會更頻繁的使用架構。

說了這麼架構的壞話,因為這是我們問題的聚焦。其實好的架構能夠省去你大量的工作,節省你很多時間。所以架構本是一個好的東西,而往往不好的是它遇到了一個不理解它的程式員。

我想我們任何一個人或集體在選擇一個開源架構的時候一定要明確自己的需要和瞭解你將使用的架構。做了必要的利弊權衡之後,你才可以確定是否使用該架構。架構不是你想用,想用都能用,否則最後知道真相的你眼淚只能掉下來。

要是朋友你能具體說明你所指的php開源mvc架構,也許我能回答得更貼題。以上僅為個人愚見。你說的開源專案範圍略顯大,也不知道你看了哪些開源項目。不同的開源項目宗旨和適用的情境是不同的,就我見過的而言,可以大致的分為下面這幾大類:
  1. 基礎工具庫,協助你搞定非常dirty或者tricky的事情,讓你專註於商務邏輯,比如前端領域的jQuery,封裝了瀏覽器安全色性的很多問題,給前端工程師提供了非常統一的介面;
  2. 工作流程架構,協助你梳理某些工作的典型工作流程,比如網站處理使用者請求,並給出響應,涉及到資料層,邏輯層,視圖層等等,這些架構大多使用了很多比較成熟的設計模式,典型的模式是MVC,當然,為了將這些架構做的更加易於擴充,還會有其他的模式被使用,比如原廠模式,代理模式,這方面的架構就太多的,每種語言都有很多,數不勝數,比如Java的Spring,PHP的Cake,Zend,Think,Javascript的backbone,nodejs的express,python的django等等。
總的來說,每種開源的項目都是作者將其工作的沉澱和技巧的積累放出來供他人使用,期望得到他人的貢獻,眾人拾柴火焰高,目前github上的很多項目都是如此,有了這些項目,後來者的工作可以說是站在巨人的肩上。我估計這2家在開發的時候,MVC思想還沒有流行到PHP吧。
現在PHP也流行MVC了,他們自己就已經有自己的一套架構體系了。
之前有稍微看了下他們的源碼,感覺都是瘋子寫的。讓我是沒法維護的,不知道他們的團隊是怎麼想的。可能是面向過程的敏捷開發吧。又或者是考慮到效能或其他。
但是看看現在的出來的開來源程式,基本上都是遵循MVC的,像PHPWIND,SHOPEX等,所以,MVC還是必然方向吧。我自己也在考慮用不用架構....感覺自己開發冗餘代碼是不是會很多...個人覺得 用架構就是依賴別人,他們完全有能力搭建自己的架構,與其花費精力去研究一個架構,還不如自己寫一個架構。(大型項目對架構的擴充修改是非常頻繁的。)WeCenter國內的一個開源社交類問答程式就是用的Mvc架構,可以去試試我覺得MVC挺好的,開發效率挺高的。讀過dedecms的源碼,寫得有點爛
  • 聯繫我們

    該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

    如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.