關鍵要點
本文最初發表於 ZenOfCoding，經作者許可在此重新發布。
一個簡單的問題促使我坐下來撰寫這篇對我大約一年前的文章的後續文章。
問：您對目前的情況有何看法？ （2017年2月24日）
答：“我認為現在主要取決於 Laravel 和 Symfony；就 PHP 框架而言。如果您要啟動一個新項目，我認為使用 CakePHP、Zend、CodeIgniter、Yii 等沒有任何特別的價值。 只有當您已經了解這些框架或擁有習慣使用它們的開發人員時，我才能看到使用它們的理由。 當真正的開發開始時，您必須能夠找到工具、插件和常見問題的答案。憑藉 Laravel 和 Symfony 社區以及新“模塊”或功能的持續開發，您永遠不會感到落後。僅 Laracasts（即使您不使用 Laravel 進行開發）就非常棒。
無論是與 iron.io 或其他 SaaS 提供商等服務的集成，對各種數據源的支持，還是像 Homestead 這樣的本地開發環境，這些框架和支持模塊都更具前瞻性。
Lumen 補充了快速 API 開發，Laravel 確實成為當今快速應用程序開發和原型設計的絕佳方法。這並不是說它在構建大型應用程序時受到某種限制。
然而，總的來說，我們確實看到了向基於容器的架構的轉變，其中 MVC 的作用要小得多。一切都是關於微服務、編排和將應用程序構建為“函數”（即 AWS Lambda 和類似服務）。也許是時候提高您的 Node.js 和 GoLang 技能了 :)”
雖然我對這個答案總體上感到滿意，但我還是忍不住認為，詳細闡述其中一些要點並重新審視現狀是個好主意。
在我開始討論“GoLang”等奇怪主題之前，讓我們先退一步，看看 2017 年 PHP MVC 框架領域的趨勢。
我認為我們過去觀察到的趨勢正在持續。 Laravel 仍在不斷發展，而其他人則落後了。 Symfony 的流行度略有上升，這可能是由於備受期待的 Symfony 3 版本發布。
（我嘗試了更具體的比較搜索，例如“CakePHP 3”或“ZF2”，但這些搜索並未產生具有統計意義的趨勢）。
今年我加入了 CodeIgniter，因為它非常流行，這一點很明顯。我收到了許多關於 CodeIgniter 的問題，以及我對其在 PHP MVC 社區中的地位的看法…… 簡而言之，CI 仍然沒有參與競爭，因為它不是真正的 MVC 框架。除了組織良好的 POPO 集合之外，我不知道該如何稱呼它……
讓我們直接引用他們的手冊中的這句話：
CodeIgniter 對 MVC 採取了相當寬鬆的方法，因為不需要模型。如果您不需要額外的分離，或者發現維護模型比您想要的更複雜，您可以忽略它們並使用控制器和視圖以最小的方式構建您的應用程序。
在構建框架方面，我完全不同意這種方法。也許它是一個不錯的樣板，這就是 CodeIgniter 流行的原因，但是框架必須強制執行某些紀律，否則最終產品將成為一堆意大利麵條代碼，包裹在某種“模式”中。
接下來，Symfony 3 為我們帶來了開發人員體驗、依賴注入和許多其他功能的一些改進。與許多 PHP 對應產品一樣，它現在提供了一個微框架。相比之下，ZF3 提供了一系列改進，例如對 PHP7 的支持（最終）甚至它自己的微框架……但正如他們的手冊所說：
對於 Zend Framework 2 MVC 用戶來說，差異很細微……
我真的很希望他們說差異很大，有一些重大的架構改進，以及一些幫助您以現代方式開發事物的精彩新模塊。唉，在大多數情況下，ZF3 與 ZF2 仍然非常相似。
這就是我今天看待 PHP 框架世界的方式：
毫無疑問，Laravel 搶盡了風頭。可用信息的數量、Laracasts、全球開發人員人才、簡單的模式實現、集成的測試工具集、Eloquent 形式的活動記錄實現、Lumen 中的輕量級版本、使用Homestead（Vagrant）的本地開發使這個框架對於新手和經驗豐富的開發人員來說都非常突出。
但是 Eloquent 模型可能會變得雜亂無章且相當龐大，可能會創建過多的 Laravel 服務（不要與微服務混淆），人們開始考慮在不合適的地方實現存儲庫模式。因此，單體應用誕生了。
如果您不熟悉活動記錄模式並且需要存儲庫的額外靈活性，或者您不喜歡看到太多匿名函數，那麼請使用 Symfony Doctrine。 我是否認為 Symfony 是通往單體應用程序的途徑？在某種程度上，是的。但是，它可能是最優雅的一個。
總的來說，我不會稱其為與去年相比的劇烈變化。儘管如此，我們仍然需要從更大的角度來看待問題：一個設計良好的應用程序不僅僅是 MVC；它還涉及基礎設施、部署管道、解耦架構。所有這些都可以在 MVC 堆棧中實現，但是需要格外注意避免單體應用。
前面我提到了微服務的興起以及提高 GoLang 或 Node 技能的必要性。 事實上，即使在 PHP MVC 文章中，如果不提及向微服務導向架構 (MOA) 的明顯轉變，那也是愚蠢的；而且它的發展勢頭之快令人難以置信。
雖然這兩個概念並非相互排斥，但沒有理由試圖在這兩者之間尋找相似之處，因為它們確實代表著不同的，儘管是相交的哲學。
例如，將您的 MVC 應用程序放在一個容器中，將 MySQL 放在另一個容器中，然後將它們鏈接在一起，並不一定代表一個合適的 MOA。 這當然是一個更好的方法，事實上，比試圖安裝 MAMP、XAMPP 或您需要獲得本地機器來服務應用程序的其他任何雜亂的東西要好得多。
此外，它還可以解決一些問題，例如在不同平台（開發人員）上輕鬆運行本地環境，以及在某些情況下部署策略，但是您的應用程序層/容器中仍然存在MVC 單體應用。
這種“破壞”正是微服務所要實現的。 雖然 MVC 通過提供一種可靠的方法來分離關注點來解決您的代碼結構和組織問題，但容器/服務/MOA 將此概念進一步擴展。
您不再只是將視圖與模型分開，而是現在將應用程序的每個“塊”或邏輯單元分離到一個獨立的服務中，該服務旨在正確處理其自身的職責。
如果您的 MVC 應用程序具有“搜索”控制器、操作和相關的模型方法，那麼我們已經有了單體應用程序的示例。
相反，使用 MOA 方法，我們將為每個處理單元提供一個服務。例如：
等等，但是所有這些“服務”不都是 MVC 堆棧的一部分嗎？是的，就是這樣。它們是我們單體應用的構建塊。
使用 MOA，每個服務都在其自己的環境中運行，作為開發人員，更重要的是作為架構師，我們可以自由地設計解決特定需求的最佳方法。
例如，如果要在 Laravel 環境中編寫圖像處理服務，我可能會使用 PHP-GD2 擴展之類的工具，這可能不是處理圖像最有效的方法。處理我的圖像處理需求的 C 服務可能會快得多，並且在規模上肯定更強大。為了進一步闡述，我們現在可以獲取圖像處理服務的輸出，並將其發送到 DataStore 服務、CloudStorage 服務和 Queue Email 服務。
使用一堆 cron 作業以及可能的一些單獨的 MVC 應用程序和自定義腳本來解決同樣的挑戰，這就是我們過去（即 2 年前）的做法。是時候向前發展了。
這就是問題開始（或結束，取決於您的前進方向）的地方。一方面，很難擴展單體應用，如果您在同一個 MVC 堆棧中構建越來越多的邏輯，您可能會遇到一個結構良好的應用程序，但其複雜性卻非常可怕。
另一方面，如果您構建了數千種不同語言的微服務，您如何管理那堆爛攤子？
已經報導了不止一個災難。
有各種容器編排工具（如 Kubernetes、Swarm、Mesos），容器部署服務（即 GKE 和 AWS ECS），但是很少有企業掌握了 Docker 架構。使用 Docker 或其他容器技術（即 GKE）構建基礎設施確實有一些成功案例。這些案例大多來自能夠承擔架構師、DevOps、DBA 和工程師資源的企業。儘管如此，就目前而言，關於如何部署一個精心編排且優雅的 MOA 的爭論不計其數。在這種情況下，一種尺寸絕對不適合所有情況，並且有許多方法可以解決您的挑戰。
無論哪種方式，您都不能獨自解決這個問題（DevOps FTW！），而且只有在達到相對較大的規模後，這個問題才真正需要解決。也許現在不是過度設計的最佳時機。
對於今天（以及那些處理複雜程度或流量需求較低的應用程序的人）來說，一個快樂的中間方法是將許多典型的服務卸載到第三方提供商。現在幾乎所有東西都可以作為服務提供。後台作業、圖像處理、身份驗證、數據分析、日誌記錄、電子郵件發送、隊列系統不需要在同一個MVC 堆棧中構建，而架構師應該考慮什麼可以卸載到SaaS 系統以獲得低月費（即Algolia搜索）或可能在某些雲空間中運行的自定義構建的docker 服務，它處理煩人的圖像處理。
我想這裡的重點是，您不應該一頭扎進重新架構項目中，不要丟棄您今天擁有的所有東西，並在任何可以想像的地方釋放 docker swarms。可以通過解耦可能的部分、了解系統中的瓶頸並將關注點分離的概念應用於這些問題區域來逐步推出改進的基礎。
2017 年將為我們帶來更多關於基於容器的 MOA 的對話和生產部署。我對Docker、使用GoLang 或Node 的觀點和胡言亂語並不意味著PHP 正在“消亡”或其他任何類似的事情……我覺得作為開發人員，我們需要保持領先地位，所以如果微服務就是它所在的地方，那麼為什麼不學習GoLang 呢？它非常適合（由於佔用空間小、速度快和並行處理）開發小型容器化應用程序。 Node 和 GoLang 很有趣，因為它們允許您構建小型服務，這些服務都是大型部落的一部分，將它們鏈接在一起，如果您願意，可以將它們作為 Docker 容器的史詩般的 swarms 發布。 然而，所有這些令人敬畏的尖端解決方案和語言並不意味著 PHP 因此不再相關或“已死”。我們肯定會在一段時間內構建 MVC 堆棧和 API 端點。
尚未通過 MOA 解決的一個問題是，雖然容器幫助我們在後端消除了單體應用，但我們仍然面臨著前端層、UI 或視圖中的許多架構問題。 我們可以構建一個非常強大的後端應用程序，但最終它將以 JSON 響應，該 JSON 必須以某種方式在客戶端應用程序中呈現。最終響應對象來自簡單的 PHP（例如，Lumen 驅動的端點（URL））還是由消息接口解耦的一系列決策和處理單元，這是否重要？這確實非常取決於您的需求和應用程序的要求。
今年，學習 Laravel，關注 Docker、GoLang，並絕對關注部署管道。從本地到生產的轉換應該比一段時間以來更加流暢，尤其是在構建 MVC 應用程序時。
PHP 中的模型-視圖-控制器 (MVC) 框架是一種設計模式，它將應用程序分成三個相互關聯的組件。模型組件對應於用戶使用與所有數據相關的邏輯。視圖組件用於應用程序的所有 UI 邏輯。另一方面，控制器充當模型和視圖組件之間的接口，以處理所有業務邏輯和傳入請求。
使用 MVC 框架進行 PHP 開發具有多種優勢。它提供了清晰的分離關注點，這使得代碼更易於維護和理解。它還促進了代碼的可重用性和可擴展性，允許開發人員創建健壯且大規模的應用程序。此外，MVC 框架通常帶有內置的工具和庫，以促進數據庫抽象、表單驗證、會話和 Cookie 處理等任務。
在 2017 年，一些頂尖的 PHP MVC 框架包括 Laravel、Symfony、CodeIgniter、Yii2 和 CakePHP。 Laravel 由於其優雅的語法、強大的功能和充滿活力的開發者社區而尤其受歡迎。 Symfony 也因其高度的靈活性和模塊化架構而被廣泛使用。
選擇合適的 PHP MVC 框架取決於幾個因素，包括項目的規模和復雜性、團隊的專業知識、框架的社區和支持、其性能和可擴展性以及涉及的學習曲線。建議在做出決定之前，根據這些因素研究和比較不同的框架。
在 PHP MVC 框架中，當用戶發送請求時，它首先轉到控制器，控制器識別要處理數據的適當模型。然後，模型與數據庫交互，處理數據並將其發送回控制器。然後，控制器加載相應的視圖，該視圖以用戶友好的格式向用戶呈現數據。
Laravel 是一個 PHP MVC 框架，以其優雅的語法和豐富的功能而聞名。它提供了用於路由、身份驗證、會話、緩存等任務的各種工具。 Laravel 還擁有一個充滿活力的社區和大量的文檔，使其成為開發人員的熱門選擇。
PHP MVC 框架的學習曲線可能會有所不同。 Laravel 和 CodeIgniter 等一些框架以其簡單性而聞名，並且相對容易學習。 Symfony 和 Yii2 等其他框架可能需要更多時間才能掌握，因為它們的功能和概念比較複雜。
是的，您可以在沒有 MVC 框架的情況下使用 PHP。但是，使用框架可以使您的開發過程更高效，並且您的代碼更易於維護，尤其是在大型應用程序中。
PHP MVC 框架中的數據庫抽像是指隱藏數據庫操作細節以避免影響應用程序其餘部分的做法。這允許開發人員使用一致的 API 與數據庫交互，而不管底層數據庫系統如何。
要開始使用 PHP MVC 框架，您應該首先了解 PHP 和麵向對象的編程基礎知識。然後，您可以選擇一個適合您需求的框架，並通過其官方文檔、在線教程和社區論壇開始學習它。
以上是2017年PHP MVC框架的狀態的詳細內容。更多資訊請關注PHP中文網其他相關文章！
