javascript - 為何在PHP 開發中需要使用 MVC 架構處理？

我第一次接觸 MVC 架構是 ThinkPhp 架構的使用。
我個人覺得這種架構用起來非常的臃腫(個人感覺)，不適合開發。(不是大公司，自己個人開發)。

那種你看不到前端介面進行開發的感覺，感覺很奇怪，總覺得和前端脫了節。

所以希望有人能給出一些合理的意見，讓我有理由相信這種模式能夠更好的協助我開發，謝謝！

回複內容：

我第一次接觸 MVC 架構是 ThinkPhp 架構的使用。
我個人覺得這種架構用起來非常的臃腫(個人感覺)，不適合開發。(不是大公司，自己個人開發)。

那種你看不到前端介面進行開發的感覺，感覺很奇怪，總覺得和前端脫了節。

所以希望有人能給出一些合理的意見，讓我有理由相信這種模式能夠更好的協助我開發，謝謝！

MVC不僅僅是一個開發模式，更是一門嚴肅的協作哲學，在軟體開發上的典型體現。

軟體開發有一句名言：“高內聚，低耦合”。在一個大型的項目中，不得不分離各個功能。這時就要求各個模組之間必須做好自己的事情，只和其他模組做必要的互動，建立必要的邏輯關係，而絕對不能深入別人的內部邏輯。

只有這樣，一個完整的項目才能一塊塊地搭建起來。如果人人的開發都是“牽一髮而動全身”的，那麼項目肯定毀於各部門之間的聯絡、交流、推諉和扯皮當中。

“看不到前端介面進行開發的感覺，感覺很奇怪，總覺得和前端脫了節”？
按我的看法，脫了節才是對的。如果把php的後端邏輯，和html的前端代碼攪成一團漿糊，那才是真正的噩夢。

這就是架構的好處：架構從結構上強制要求商務邏輯的分離。這樣對個人容易板正習慣，對群體容易協同工作。

所以學習架構不僅是應用性的，更是一個發展性的習慣。因為如果真的很嚴肅把對待php開發當作事業，那麼融入群體開發是早晚的事。這樣，就算沒有成型的架構，也會有一個群體內部協調好的一個業務分離的結構。如果不能適應、難以遵守恐怕就麻煩了。

前端看不到？好整，我寧可先擺個最醜陋（甚至沒有CSS）的前端，調試穩定了，然後再到網上去扒樣式。

MVC架構，到頭來多半是個觀念，其實也未必需要用成型架構來實現。你可以先考慮學一套模板引擎，徹底拋開PHP單純做前台的HTML/CSS（V）；然後把資料庫的讀寫操作集中成塊（M）；最後編製一套網址結構，用來調用模板或調用後台操作（C），其實這樣MVC結構，也就自然做出來了。

MVC 不光是 PHP 的概念，是 PHP 從其他語言借鑒過來的，現在差不多所有 PHP 架構都有某種形式的 MVC 思想。

MVC 的核心是將 資料操作(Model), 前端頁面(View), 商務邏輯(Controller) 分離，每個部分可以單獨工作，替換。

比如，前端頁面和商務邏輯分離，可以直接把前端頁面交給前端設計師來修改，前端設計師無需瞭解 PHP 和商務邏輯。這不是脫節，這是分工。
比如當從一種資料來源(資料庫)更換到另外一種資料來源時，只需修改 Model 即可，前端和商務邏輯都無需修改。

另外，你不覺得把這三部分分開，代碼會更加清晰麼。想象一下在 PHP 裡面拼 HTML, 以及在 HTML 裡反覆開關 PHP 標記，這是有多麼蛋疼。

MVC 算是目前的趨勢吧，個人以為只要一個應用有一個以上的頁面，都有採用 MVC 模式的必要。
至於你說比較臃腫...這可能是 ThinkPHP 比較臃腫吧，MVC 只是思想，也是有很多輕量級的 MVC 架構的。

樓上對MVC做了很多解釋，不想多說了，說一下你困惑的原因吧：

1. 你做得項目規模太小，MVC無法發揮優勢。因此，如果確實是小項目，沒必要一定要用MVC模式開發，自己怎麼快速方便怎麼來就行，或者選一些輕量級的架構
2. 你是個人開發而不是團隊開發，MVC仍然無法發揮優勢。當你經曆了多人協作開發一個項目之後，你自然就明白了，有架構的既有規則在那裡規範著，是多麼重要，多麼方便的事情
3. 你做的可能基本是一次性開發，而不是持續迭代，或者後期維護。當一個大型項目，需要不斷擴充功能，修改資料層、邏輯層、表現層的東西的時候，你也就會明白MVC模式帶來的優越性了

總之，合適的情境下使用合適的工具，不要拘泥。同時，也不要覺得目前一些已經被普遍證明的設計模式沒什麼用處，雖然你現在可能用不上，但是仍然應該多使用，多研究，多積累，總有一天會大徹大悟的。

看來樓主應該是剛工作不久或是學生吧？
你有這樣的感覺因為你在做的是“個人開發”，如果你跟我一樣苦逼的面對著原始碼就上百MB的操蛋項目時就不會有這樣的疑問了

PHP本來就是解釋型語言，其實沒必要過分強調MVC。

不過隨著團隊發展，根據分工進行必要的商務邏輯分割還是必要的。

從我個人學習的經曆來看，很多一些目前看起來覺得繁瑣的東西，其實都是有一定用處的，只是這個適用情境目前還沒有遇到，或者沒有去深入挖掘，體會不到這方面的好處。

軟體開發到了一定的規模，就越加強調分層的概念，把不同的功能進行隔離，也就是解耦，在這個過程中，MVC就是一種比較典型的宏觀意義上的分層的概念，把最基本的三層概念進行區分。

其實thinkphp還算不上臃腫的架構，也是比較輕量級的，建議題主在學習的過程中，不要去特別在意這些概念，一步一步學下去，即使某一種思想是錯的，對自己也是一種補充。用完架構，可以順勢去看一下架構的原始碼，對自己也是一種提升

規模問題吧？做的東西太小確實沒什麼用還不如直接寫來得好，但是綜合考慮擴充什麼的話，優勢就逐漸體現出來了。

我這裡說一下上面幾位沒有說清楚的：開發在一個產品或者是項目中只是佔了一部分。 如果你僅僅只是為了開發能夠舒服，並且你是個體開發人員，那麼也許MVC對你來說意義不算太大。 但是對於團隊開發以及後期維護來說，MVC這個概念你是絕對不能忽視的。 試想一下，一個七八個人的團隊，開發一個商務邏輯十分多的產品，而對於業務、視圖以及資料你不能很好地分離，甚至七八個人需要同時操作一個地方。效率會高嗎？ 這僅僅還只是開發層面上的。 要是後期維護呢？對於一些線上的產品，開發週期比維護周期可能要短得多。要是不能做好模組化管理，後期的維護將是一件十分蛋疼的事情。 你覺得對嗎？

項目你已經開發好了，但是客戶突然要求你能做到多個前端模板，並且可以隨意切換，如果你用html混雜模式，是不是要哭了？不用模板分離，業務分離，如果你的代碼交給別人去看，那人家簡直要瘋掉

ThinkPHP 算不上臃腫吧，你是沒見過YII Laravel Zend ……

thinkphp就是文法太奇葩了，學習成本有點高，可以看下corephp，非常簡單模板文法幾乎不用學習，一兩分鐘就能學會了

