關鍵要點

• Laravel 和 Symfony 目前是領先的 PHP MVC 框架，擁有強大的社區(qū)和持續(xù)開發(fā)的新功能。
• 微服務和基於容器的架構的興起正在改變 MVC 的作用，轉(zhuǎn)向?qū)贸绦驑嫿椤昂瘮?shù)”。
• 雖然 Laravel 處於領先地位，但大型 Eloquent 模型和過多的服務可能會使其變得複雜，從而導致單體應用的產(chǎn)生。
• Symfony 雖然有時會導致單體應用程序，但它通過使用存儲庫提供了優(yōu)雅性和靈活性。
• 微服務的出現(xiàn)並不意味著 PHP 正在消亡，但開發(fā)人員應該保持領先地位，並考慮學習 GoLang 或 Node.js。

本文最初發(fā)表於 ZenOfCoding，經(jīng)作者許可在此重新發(fā)布。

一個簡單的問題促使我坐下來撰寫這篇對我大約一年前的文章的後續(xù)文章。

問：您對目前的情況有何看法？ （2017年2月24日）

答：“我認為現(xiàn)在主要取決於 Laravel 和 Symfony；就 PHP 框架而言。如果您要啟動一個新項目，我認為使用 CakePHP、Zend、CodeIgniter、Yii 等沒有任何特別的價值。 只有當您已經(jīng)了解這些框架或擁有習慣使用它們的開發(fā)人員時，我才能看到使用它們的理由。 當真正的開發(fā)開始時，您必須能夠找到工具、插件和常見問題的答案。憑藉 Laravel 和 Symfony 社區(qū)以及新“模塊”或功能的持續(xù)開發(fā)，您永遠不會感到落後。僅 Laracasts（即使您不使用 Laravel 進行開發(fā)）就非常棒。

無論是與 iron.io 或其他 SaaS 提供商等服務的集成，對各種數(shù)據(jù)源的支持，還是像 Homestead 這樣的本地開發(fā)環(huán)境，這些框架和支持模塊都更具前瞻性。

Lumen 補充了快速 API 開發(fā)，Laravel 確實成為當今快速應用程序開發(fā)和原型設計的絕佳方法。這並不是說它在構建大型應用程序時受到某種限制。

然而，總的來說，我們確實看到了向基於容器的架構的轉(zhuǎn)變，其中 MVC 的作用要小得多。一切都是關於微服務、編排和將應用程序構建為“函數(shù)”（即 AWS Lambda 和類似服務）。也許是時候提高您的 Node.js 和 GoLang 技能了 :)”

雖然我對這個答案總體上感到滿意，但我還是忍不住認為，詳細闡述其中一些要點並重新審視現(xiàn)狀是個好主意。

在我開始討論“GoLang”等奇怪主題之前，讓我們先退一步，看看 2017 年 PHP MVC 框架領域的趨勢。

我認為我們過去觀察到的趨勢正在持續(xù)。 Laravel 仍在不斷發(fā)展，而其他人則落後了。 Symfony 的流行度略有上升，這可能是由於備受期待的 Symfony 3 版本發(fā)布。

（我嘗試了更具體的比較搜索，例如“CakePHP 3”或“ZF2”，但這些搜索並未產(chǎn)生具有統(tǒng)計意義的趨勢）。

今年我加入了 CodeIgniter，因為它非常流行，這一點很明顯。我收到了許多關於 CodeIgniter 的問題，以及我對其在 PHP MVC 社區(qū)中的地位的看法…… 簡而言之，CI 仍然沒有參與競爭，因為它不是真正的 MVC 框架。除了組織良好的 POPO 集合之外，我不知道該如何稱呼它……

讓我們直接引用他們的手冊中的這句話：

CodeIgniter 對 MVC 採取了相當寬鬆的方法，因為不需要模型。如果您不需要額外的分離，或者發(fā)現(xiàn)維護模型比您想要的更複雜，您可以忽略它們並使用控制器和視圖以最小的方式構建您的應用程序。

在構建框架方面，我完全不同意這種方法。也許它是一個不錯的樣板，這就是 CodeIgniter 流行的原因，但是框架必須強制執(zhí)行某些紀律，否則最終產(chǎn)品將成為一堆意大利麵條代碼，包裹在某種“模式”中。

接下來，Symfony 3 為我們帶來了開發(fā)人員體驗、依賴注入和許多其他功能的一些改進。與許多 PHP 對應產(chǎn)品一樣，它現(xiàn)在提供了一個微框架。相比之下，ZF3 提供了一系列改進，例如對 PHP7 的支持（最終）甚至它自己的微框架……但正如他們的手冊所說：

對於 Zend Framework 2 MVC 用戶來說，差異很細微……

我真的很希望他們說差異很大，有一些重大的架構改進，以及一些幫助您以現(xiàn)代方式開發(fā)事物的精彩新模塊。唉，在大多數(shù)情況下，ZF3 與 ZF2 仍然非常相似。

長話短說

這就是我今天看待 PHP 框架世界的方式：

1. Symfony 或 Laravel，取決於您的需求
2. 其他的

毫無疑問，Laravel 搶盡了風頭。可用信息的數(shù)量、Laracasts、全球開發(fā)人員人才、簡單的模式實現(xiàn)、集成的測試工具集、Eloquent 形式的活動記錄實現(xiàn)、Lumen 中的輕量級版本、使用Homestead（Vagrant）的本地開發(fā)使這個框架對於新手和經(jīng)驗豐富的開發(fā)人員來說都非常突出。

但是 Eloquent 模型可能會變得雜亂無章且相當龐大，可能會創(chuàng)建過多的 Laravel 服務（不要與微服務混淆），人們開始考慮在不合適的地方實現(xiàn)存儲庫模式。因此，單體應用誕生了。

如果您不熟悉活動記錄模式並且需要存儲庫的額外靈活性，或者您不喜歡看到太多匿名函數(shù)，那麼請使用 Symfony Doctrine。 我是否認為 Symfony 是通往單體應用程序的途徑？在某種程度上，是的。但是，它可能是最優(yōu)雅的一個。

總的來說，我不會稱其為與去年相比的劇烈變化。儘管如此，我們?nèi)匀恍枰獜母蟮慕嵌葋砜创龁栴}：一個設計良好的應用程序不僅僅是 MVC；它還涉及基礎設施、部署管道、解耦架構。所有這些都可以在 MVC 堆棧中實現(xiàn)，但是需要格外注意避免單體應用。

微服務的出現(xiàn)

前面我提到了微服務的興起以及提高 GoLang 或 Node 技能的必要性。 事實上，即使在 PHP MVC 文章中，如果不提及向微服務導向架構 (MOA) 的明顯轉(zhuǎn)變，那也是愚蠢的；而且它的發(fā)展勢頭之快令人難以置信。

雖然這兩個概念並非相互排斥，但沒有理由試圖在這兩者之間尋找相似之處，因為它們確實代表著不同的，儘管是相交的哲學。

例如，將您的 MVC 應用程序放在一個容器中，將 MySQL 放在另一個容器中，然後將它們鏈接在一起，並不一定代表一個合適的 MOA。 這當然是一個更好的方法，事實上，比試圖安裝 MAMP、XAMPP 或您需要獲得本地機器來服務應用程序的其他任何雜亂的東西要好得多。

此外，它還可以解決一些問題，例如在不同平臺（開發(fā)人員）上輕鬆運行本地環(huán)境，以及在某些情況下部署策略，但是您的應用程序?qū)?容器中仍然存在MVC 單體應用。

單體應用的破壞

這種“破壞”正是微服務所要實現(xiàn)的。 雖然 MVC 通過提供一種可靠的方法來分離關注點來解決您的代碼結構和組織問題，但容器/服務/MOA 將此概念進一步擴展。

您不再只是將視圖與模型分開，而是現(xiàn)在將應用程序的每個“塊”或邏輯單元分離到一個獨立的服務中，該服務旨在正確處理其自身的職責。

如果您的 MVC 應用程序具有“搜索”控制器、操作和相關的模型方法，那麼我們已經(jīng)有了單體應用程序的示例。

相反，使用 MOA 方法，我們將為每個處理單元提供一個服務。例如：

• 路由服務
• 請求服務
• 查詢服務
• 數(shù)據(jù)源服務
• 響應服務

等等，但是所有這些“服務”不都是 MVC 堆棧的一部分嗎？是的，就是這樣。它們是我們單體應用的構建塊。

使用 MOA，每個服務都在其自己的環(huán)境中運行，作為開發(fā)人員，更重要的是作為架構師，我們可以自由地設計解決特定需求的最佳方法。

例如，如果要在 Laravel 環(huán)境中編寫圖像處理服務，我可能會使用 PHP-GD2 擴展之類的工具，這可能不是處理圖像最有效的方法。處理我的圖像處理需求的 C 服務可能會快得多，並且在規(guī)模上肯定更強大。為了進一步闡述，我們現(xiàn)在可以獲取圖像處理服務的輸出，並將其發(fā)送到 DataStore 服務、CloudStorage 服務和 Queue Email 服務。

使用一堆 cron 作業(yè)以及可能的一些單獨的 MVC 應用程序和自定義腳本來解決同樣的挑戰(zhàn)，這就是我們過去（即 2 年前）的做法。是時候向前發(fā)展了。

可擴展性

這就是問題開始（或結束，取決於您的前進方向）的地方。一方面，很難擴展單體應用，如果您在同一個 MVC 堆棧中構建越來越多的邏輯，您可能會遇到一個結構良好的應用程序，但其複雜性卻非?？膳?。

另一方面，如果您構建了數(shù)千種不同語言的微服務，您如何管理那堆爛攤子？

已經(jīng)報導了不止一個災難。

有各種容器編排工具（如 Kubernetes、Swarm、Mesos），容器部署服務（即 GKE 和 AWS ECS），但是很少有企業(yè)掌握了 Docker 架構。使用 Docker 或其他容器技術（即 GKE）構建基礎設施確實有一些成功案例。這些案例大多來自能夠承擔架構師、DevOps、DBA 和工程師資源的企業(yè)。儘管如此，就目前而言，關於如何部署一個精心編排且優(yōu)雅的 MOA 的爭論不計其數(shù)。在這種情況下，一種尺寸絕對不適合所有情況，並且有許多方法可以解決您的挑戰(zhàn)。

無論哪種方式，您都不能獨自解決這個問題（DevOps FTW?。?，而且只有在達到相對較大的規(guī)模後，這個問題才真正需要解決。也許現(xiàn)在不是過度設計的最佳時機。

對於今天（以及那些處理複雜程度或流量需求較低的應用程序的人）來說，一個快樂的中間方法是將許多典型的服務卸載到第三方提供商。現(xiàn)在幾乎所有東西都可以作為服務提供。後臺作業(yè)、圖像處理、身份驗證、數(shù)據(jù)分析、日誌記錄、電子郵件發(fā)送、隊列系統(tǒng)不需要在同一個MVC 堆棧中構建，而架構師應該考慮什麼可以卸載到SaaS 系統(tǒng)以獲得低月費（即Algolia搜索）或可能在某些雲(yún)空間中運行的自定義構建的docker 服務，它處理煩人的圖像處理。

我想這裡的重點是，您不應該一頭扎進重新架構項目中，不要丟棄您今天擁有的所有東西，並在任何可以想像的地方釋放 docker swarms?？梢酝ㄟ^解耦可能的部分、了解系統(tǒng)中的瓶頸並將關注點分離的概念應用於這些問題區(qū)域來逐步推出改進的基礎。

結論

2017 年將為我們帶來更多關於基於容器的 MOA 的對話和生產(chǎn)部署。我對Docker、使用GoLang 或Node 的觀點和胡言亂語並不意味著PHP 正在“消亡”或其他任何類似的事情……我覺得作為開發(fā)人員，我們需要保持領先地位，所以如果微服務就是它所在的地方，那麼為什麼不學習GoLang 呢？它非常適合（由於佔用空間小、速度快和並行處理）開發(fā)小型容器化應用程序。 Node 和 GoLang 很有趣，因為它們允許您構建小型服務，這些服務都是大型部落的一部分，將它們鏈接在一起，如果您願意，可以將它們作為 Docker 容器的史詩般的 swarms 發(fā)布。 然而，所有這些令人敬畏的尖端解決方案和語言並不意味著 PHP 因此不再相關或“已死”。我們肯定會在一段時間內(nèi)構建 MVC 堆棧和 API 端點。

尚未通過 MOA 解決的一個問題是，雖然容器幫助我們在後端消除了單體應用，但我們?nèi)匀幻媾R著前端層、UI 或視圖中的許多架構問題。 我們可以構建一個非常強大的後端應用程序，但最終它將以 JSON 響應，該 JSON 必須以某種方式在客戶端應用程序中呈現(xiàn)。最終響應對象來自簡單的 PHP（例如，Lumen 驅(qū)動的端點（URL））還是由消息接口解耦的一系列決策和處理單元，這是否重要？這確實非常取決於您的需求和應用程序的要求。

今年，學習 Laravel，關注 Docker、GoLang，並絕對關注部署管道。從本地到生產(chǎn)的轉(zhuǎn)換應該比一段時間以來更加流暢，尤其是在構建 MVC 應用程序時。

關於 PHP MVC 框架的常見問題

什麼是 PHP 中的 MVC 框架？

PHP 中的模型-視圖-控制器 (MVC) 框架是一種設計模式，它將應用程序分成三個相互關聯(lián)的組件。模型組件對應於用戶使用與所有數(shù)據(jù)相關的邏輯。視圖組件用於應用程序的所有 UI 邏輯。另一方面，控制器充當模型和視圖組件之間的接口，以處理所有業(yè)務邏輯和傳入請求。

為什麼我應該使用 MVC 框架進行 PHP 開發(fā)？

使用 MVC 框架進行 PHP 開發(fā)具有多種優(yōu)勢。它提供了清晰的分離關注點，這使得代碼更易於維護和理解。它還促進了代碼的可重用性和可擴展性，允許開發(fā)人員創(chuàng)建健壯且大規(guī)模的應用程序。此外，MVC 框架通常帶有內(nèi)置的工具和庫，以促進數(shù)據(jù)庫抽象、表單驗證、會話和 Cookie 處理等任務。

2017 年最頂尖的 PHP MVC 框架是什麼？

在 2017 年，一些頂尖的 PHP MVC 框架包括 Laravel、Symfony、CodeIgniter、Yii2 和 CakePHP。 Laravel 由於其優(yōu)雅的語法、強大的功能和充滿活力的開發(fā)者社區(qū)而尤其受歡迎。 Symfony 也因其高度的靈活性和模塊化架構而被廣泛使用。

如何為我的項目選擇合適的 PHP MVC 框架？

選擇合適的 PHP MVC 框架取決於幾個因素，包括項目的規(guī)模和復雜性、團隊的專業(yè)知識、框架的社區(qū)和支持、其性能和可擴展性以及涉及的學習曲線。建議在做出決定之前，根據(jù)這些因素研究和比較不同的框架。

MVC 模式如何在 PHP 框架中工作？

在 PHP MVC 框架中，當用戶發(fā)送請求時，它首先轉(zhuǎn)到控制器，控制器識別要處理數(shù)據(jù)的適當模型。然後，模型與數(shù)據(jù)庫交互，處理數(shù)據(jù)並將其發(fā)送回控制器。然後，控制器加載相應的視圖，該視圖以用戶友好的格式向用戶呈現(xiàn)數(shù)據(jù)。

什麼是 Laravel，為什麼它如此受歡迎？

Laravel 是一個 PHP MVC 框架，以其優(yōu)雅的語法和豐富的功能而聞名。它提供了用於路由、身份驗證、會話、緩存等任務的各種工具。 Laravel 還擁有一個充滿活力的社區(qū)和大量的文檔，使其成為開發(fā)人員的熱門選擇。

PHP MVC 框架的學習曲線如何？

PHP MVC 框架的學習曲線可能會有所不同。 Laravel 和 CodeIgniter 等一些框架以其簡單性而聞名，並且相對容易學習。 Symfony 和 Yii2 等其他框架可能需要更多時間才能掌握，因為它們的功能和概念比較複雜。

我可以在沒有 MVC 框架的情況下使用 PHP 嗎？

是的，您可以在沒有 MVC 框架的情況下使用 PHP。但是，使用框架可以使您的開發(fā)過程更高效，並且您的代碼更易於維護，尤其是在大型應用程序中。

什麼是 PHP MVC 框架中的數(shù)據(jù)庫抽象？

PHP MVC 框架中的數(shù)據(jù)庫抽像是指隱藏數(shù)據(jù)庫操作細節(jié)以避免影響應用程序其餘部分的做法。這允許開發(fā)人員使用一致的 API 與數(shù)據(jù)庫交互，而不管底層數(shù)據(jù)庫系統(tǒng)如何。

如何開始使用 PHP MVC 框架？

要開始使用 PHP MVC 框架，您應該首先了解 PHP 和麵向?qū)ο蟮木幊袒A知識。然後，您可以選擇一個適合您需求的框架，並通過其官方文檔、在線教程和社區(qū)論壇開始學習它。

以上是2017年PHP MVC框架的狀態(tài)的詳細內(nèi)容。更多資訊請關注PHP中文網(wǎng)其他相關文章！