什麼是HMVC模式？

124

閱讀Kohana的文檔，我發現3.0版本的主要區別在於它遵循HMVC模式而不是2.x版本的MVC模式。 Kohana的文檔和維基百科的文章並沒有給我一個清晰的想法。什麼是HMVC模式？

所以問題：什麼是HMVC模式，它與MVC有什麼不同？

來源

2010-02-15 Matteo Riva

+30

Kohana論壇內就這個話題進行了討論。你可能會發現它是有幫助的：http://forum.kohanaframework.org/discussion/1681 – Sampson 2010-02-15 00:27:13

@喬納森不是一個答案，不是評論......？ – 2010-02-15 00:31:32

@喬納森只是，你知道，我無法贊成它。 – 2010-02-15 00:33:00

薩姆去弗雷西（的Kohana的開發者之一）寫了一個相當in-depth article about HMVC，它是什麼，以及如何使用。

Link是死：新幹線 - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

來源

2010-03-01 13:14:12 shadowhand

感謝您提供了一個很好的鏈接，同時結帳這個http://www.javaworld.com/jw-07-2000/jw-0721-hmvc.html – 2013-05-01 17:30:05

鏈接已經死了 – Sithu 2017-03-03 09:34:24

@Sithu https://web.archive.org/web/20160220044633/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc – 2017-03-21 19:58:10

HMVC與「基於組件的」調度方法密切相關。基本上，每個控制器都可以獨立充當調度員，而不是隻有一個調度程序，它委派給一個控制器。這給你一個控制器的層次結構。這個設計更加靈活，並且可以更好地封裝代碼，但代價更高。 Konstrukt圍繞此模式而設計。

也看到這個答案：https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411

來源

2010-02-15 10:43:56 troelskn

在Kohana中，至少一個HMVC的要求是服務「內部」 HTTP請求：而不是發行在網絡上，它的路由，出動並由框架本身處理。名稱「HMVC」和「MVC」的相似性令人困惑，因爲它暗示了事實上並不存在的術語之間的基礎連接：一個不是另一個的小變體或修飾，它們是完全不同的事物。（HMVC也被描述爲沒有客戶端HTTP請求的Ajax。）Kohana強調並支持「HMVC」意味着該框架對基於HTTP的面向服務架構的強大支持。

這種架構模式的優點是，由於內部和外部請求使用了相同的「調用約定」，所以在需要時將「內部」服務請求轉換爲「外部」請求或反之亦然。

雖然這是一個明智的架構模式，但給它起自己的名字似乎沒有必要（Symfony2描述了相同的概念「sub-requests」），事實上這個名稱似乎是一個誤稱：沒有特別的要求或需要請求形成一個層次結構（除每個命令式程序的標準調用圖之外）;例如，請求很容易遞歸。

[更新2011年4月，2012年3月：響應意見上擴展的答案。]

來源

2010-07-05 22:33:36 mjs

能夠將「內部」對'外部'請求的服務請求，如果需要，您可以更容易地向外擴展，即將一些應用程序模塊移動到它們自己的服務器上。 – 2011-01-27 23:12:45

是的，嘗試實現一個內部的Web服務，沒有它，只是爲了看看它實際上「並不重要」。 – Kemo 2011-04-23 09:52:12

@Kemo我認爲這是一個很好的建築，我只是覺得這個名字很混亂，這意味着Kohana做的事情特別不尋常。 – mjs 2011-04-24 17:45:00

我目前在開發自己的PHP 5.3 HMVC框架調用Alloy的過程。由於我大量投資並在HMVC上銷售，我認爲我可以提供一個不同的觀點，也許更好地解釋爲什麼應該使用HMVC及其帶來的好處。

使用HMVC架構的最大實際好處是內容結構的「widgetization」。一個示例可能是評論，評分，Twitter或博客RSS源顯示，或顯示電子商務網站的購物車內容。它本質上是一段內容，需要跨多個頁面顯示，甚至可能在不同的地方顯示，具體取決於主HTTP請求的上下文。

傳統的MVC框架通常不會爲這些類型的內容結構提供直接的答案，因此人們通常最終會使用自定義幫助程序，創建自己的窗口小部件結構或庫文件或拉入不相關的數據來重複和切換佈局從主要請求的控制器推到視圖並呈現局部。這些都不是特別好的選擇，因爲渲染特定內容或加載所需數據的責任最終會泄漏到多個區域並在使用它的地方複製。

HMVC或者特別是向子控制器分派子請求以處理這些責任的能力是顯而易見的解決方案。如果您考慮自己在做什麼，它就完全適合Controller結構。您需要加載一些關於評論的數據，並以HTML格式顯示它們。因此，您使用一些參數向評論控制器發送請求，與模型交互，選擇視圖，視圖顯示內容。唯一的區別是你希望評論以內聯方式顯示在用戶正在查看的博客文章的下方，而不是完全獨立的完整評論頁面（儘管使用HMVC方法，實際上可以使用相同的控制器同時處理內部和外部請求，並「殺死俗話說「兩鳥一石」。在這方面，HMVC實際上只是爭取提高代碼模塊性，可重用性和保持更好的問題分離的天然副產品。這是HMVC的賣點。

所以雖然Sam de Freyssinet's TechPortal article與HMVC的擴展很有意思，但90％以上的使用HMVC框架的人將不會從中獲得真正實用的日常好處。

來源

2011-04-20 20:21:37

是的，這是我在現實世界中使用它的想法，但從這個角度來看，這個名稱並不適合，因爲HMVC中的H是誤導性的（沒有真正的層次結構）。 – 2011-04-20 21:34:37

是的，你說得很好。我實際上分享了這個觀點，並給了它另一個名字 - 「嵌套MVC」 - 我在2011年的ConfuTour上做了演示。它在Slideshare上，第20張幻燈片上：http://www.slideshare.net/vlucas/合金-hmvc-php-framework – 2011-04-20 22:23:01

HMVC如何處理模塊樹中多次返回的需求？比如整理頭部/ body/footer內容，JS/Css依賴關係和模塊之間的相互關係。活動？鉤？單身網頁框架？結構化返回對象？ – scipilot 2015-02-15 21:46:32

HMVC是分層模型視圖控制器。在正常的MVC中，每個GUI對象都有它的MVC。但不同於HMVC，父GUI對象和子GUI對象之間沒有任何關係。在HMVC中，每個GUI對象都有權訪問其子對象，並且每個子對象都可以訪問其父對象。

所以在每個視圖中都有一個父視圖。通過它可以訪問它的父視圖。對於每個控制器有一個父控制器，通過它可以將事件傳遞給父控制器（如果事件不是在其範圍內。）

~~詳細說明請點擊here~~

新鏈接this address

來源

2011-06-07 09:39:41

好的答案的標記不僅僅是一個沒有其他信息或上下文的鏈接。請你可以花費你的回答，並總結鏈接文章的相關部分？ – Kev 2011-06-07 16:17:30

@Sanjay，你有什麼理由將HMVC文章鏈接的目的地更改爲移動gwt狀態鏈接的目的地？ – 2013-02-27 20:00:28

@科赫..我沒有改變鏈接...即使我不知道是誰改變了它....順便說一句，我把它鏈接到原來的鏈接。 – 2013-03-04 17:40:36

什麼是HMVC模式？

回答

相關問題