MVC-問題還是解決方案？

>存儲庫，適配器，MVC，固體，RTFM…網絡不斷地將這些術語拋向PHP開發人員。 我厭倦了。足夠的命令；告訴我小貓！

>

密鑰點：

MVC不是Web應用程序複雜性的魔術子彈。 乾淨，可重複使用，脫鉤的代碼是真正的解決方案，這取決於開發人員。 與任何模式一樣，MVC是一種工具。 使用良好，它可以提高靈活性和易用性。但這是極限用途和濫用的。
>不要盲目應用模式。了解他們的優勢和缺點；選擇適合工作的正確工具。
軟件解決問題：

我們構建了解決問題的軟件。 每條代碼都解決了特定的需求，無論是拯救世界還是展示可愛的小貓。 尊重該目的。 這些問題的解決方案融合到較大的系統中。 但是，我們如何確保我們的解決方案有效，可理解和可維護？

“一個尺寸適合所有”神話：

> MVC通常是Web應用程序的唯一可行解決方案。 社區經常批評那些不使用它的人，很少解釋為什麼

MVC據稱是優越的。

>

為什麼MVC炒作？ 通常引用的好處包括：

降低代碼複雜度

>代碼可重用性

提高靈活性

脫鉤代碼

但是這些主張是真的嗎？其他模式是否缺乏這些優勢？ 編號
MVC並不能固有地解決複雜性，可重複性，靈活性或去耦。
• >開發人員
編寫乾淨，靈活和可重複使用的代碼。 我們不需要MVC比需要jQuery使用
• 。 出色的軟件在MVC之前就已經存在了，並且將繼續沒有它。
> MVC是一種模式，而不是靈丹妙藥。 這是眾多：適配器，工廠，單例，模塊，口譯員，觀察者...

模式有助於他們無法解決：

> >模式可幫助我們編寫更好的代碼。它們代表最佳實踐，但最佳實踐取決於問題。船非常適合水旅行，而不是耕地。 document.getElementById()每個模式都有優勢和劣勢。工廠模式在對象創建時出色。模塊模式有助於在缺乏強大模塊支持的語言中構造代碼（例如JavaScript）。觀察者模式在事件處理中閃耀。 MVC有助於解耦演示，數據和邏輯。 MVC的過度使用源於誤導的信念，即這是PHP Web應用程序的通用解決方案。 出現了嚴格的規則：模型鏡像數據庫行，薄控制器，模板引擎...然後是“脂肪控制器”以及HMVC，MVA，MVP，MVP，MVP，MVVM，PAC，PAC ...

的擴散。

> mvc：新的singleton（或IE8）：

>MVC並不孤單。 正如基思（Keith）指出的那樣，單身模式被過度使用，以避免全球的邪惡，導致

而不是Global::getInstance()->var>。 $globalVar>

模式是工具，開發人員是手工藝人：

> >模式很有價值，但明智而周到地使用它們。 沒有什麼比開發人員誤用模式更糟糕的了。 >

不要重新發明輪子。 許多聰明的開發人員在您面前解決了類似的問題。

>在PHP中與數據庫集成鬥爭？ MVC或多層體系結構可能會有所幫助。 懶惰加載問題？ 單身可能是合適的。 物體創造麻煩？ 工廠模式可以幫助您。 服務間溝通問題？ 適配器是您的朋友。

結論：

>不同的模式提供了不同的好處。根據問題明智地選擇。 如果您將MVC用於單頁應用程序，請刪除它。 > 可能與您同在！

>

經常詢問有關MVC和PHP框架的問題：

>

（本節在很大程度上保持不變，因為它是MVC和PHP框架的良好概述）。以及它們對各種項目類型的適用性。 這裡不需要更改。 >

以上是MVC-問題還是解決方案？的詳細內容。更多資訊請關注PHP中文網其他相關文章！