Jaki jest wzorzec HMVC?

Czytając dokumentację Kohany, dowiedziałem się, że główna różnica w wersji 3.0 polega na tym, że jest zgodna ze wzorcem HMVC zamiast MVC, jak robi to wersja 2.x. Strona o tym w dokumentach Kohany i ta na Wikipedii nie dały mi jasnego pojęcia.

Pytanie: czym jest wzorzec HMVC i czym różni się od MVC?

Sam de Freyssinet (jeden z programistów Kohana) napisał dość dogłębny artykuł o HMVC , czym jest i jak można go używać.

Link nie żyje: Nowy link - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Obecnie jestem w trakcie tworzenia własnego frameworka PHP 5.3 HMVC o nazwie Alloy . Ponieważ jestem mocno zainwestowany i sprzedawany na HMVC, pomyślałem, że mógłbym zaproponować inny punkt widzenia i być może lepsze wyjaśnienie, dlaczego należy używać HMVC i jakie przynosi korzyści.

Największą praktyczną zaletą korzystania z architektury HMVC jest „widżetizacja” struktur treści. Przykładem mogą być komentarze, oceny, wyświetlanie kanałów RSS na Twitterze lub blogu lub wyświetlanie zawartości koszyka na zakupy w witrynie handlu elektronicznego. Zasadniczo jest to fragment treści, który musi być wyświetlany na wielu stronach, a być może nawet w różnych miejscach, w zależności od kontekstu głównego żądania HTTP.

Tradycyjne frameworki MVC na ogół nie zapewniają bezpośredniej odpowiedzi na tego typu struktury treści, więc ludzie generalnie powielają i przełączają układy, używając niestandardowych pomocników, tworząc własne struktury widżetów lub pliki biblioteczne lub pobierając niepowiązane dane z głównego żądanego Kontroler, aby przejść do widoku i renderować w części. Żadna z tych opcji nie jest szczególnie dobra, ponieważ odpowiedzialność za renderowanie określonego fragmentu treści lub ładowanie wymaganych danych kończy się przeciekiem do wielu obszarów i powielaniem w miejscach, w których są używane.

HMVC, a konkretnie możliwość wysyłania żądań podrzędnych do kontrolera w celu obsługi tych obowiązków, jest oczywistym rozwiązaniem. Jeśli myślisz o tym, co robisz, dokładnie pasuje to do struktury kontrolera. Musisz załadować dane o komentarzach i wyświetlić je w formacie HTML. Wysyłasz więc żądanie do kontrolera komentarzy z niektórymi parametrami, współdziała z modelem, wybiera widok, a widok wyświetla zawartość. Jedyną różnicą jest to, że chcesz, aby komentarze były wyświetlane w tekście, pod artykułem na blogu, który przegląda użytkownik, zamiast na całkowicie oddzielnej stronie z komentarzami (chociaż w podejściu HMVC możesz obsługiwać zarówno żądania wewnętrzne, jak i zewnętrzne za pomocą tego samego kontrolera dwie pieczenie na jednym ogniu ”, jak to się mówi). Pod tym względem, HMVC jest tak naprawdę naturalnym produktem ubocznym dążenia do zwiększonej modułowości kodu, możliwości ponownego wykorzystania i lepszego rozdzielenia problemów. To jest punkt sprzedaży HMVC.

Więc chociaż artykuł Sama de Freyssineta w TechPortalu na temat skalowania z HMVC jest interesujący do przemyślenia, nie jest to miejsce, w którym ponad 90% osób korzystających ze struktur HMVC odniesie z tego rzeczywiste, praktyczne, codzienne korzyści.

HMVC jest ściśle powiązany z podejściem do wysyłki opartym na komponentach. Zasadniczo, zamiast mieć jednego dyspozytora, który deleguje do kontrolera, każdy kontroler może sam działać jako dyspozytor. Zapewnia to hierarchię kontrolerów. Projekt jest bardziej elastyczny i powoduje lepszą hermetyzację kodu, ale za cenę wyższej abstrakcji. Konstrukt jest zaprojektowany wokół tego wzoru.

Zobacz także tę odpowiedź: /programming/115629/simplest-php-routing-framework/120411#120411

Przynajmniej w Kohanie żądanie HMVC jest żądaniem HTTP, które jest obsługiwane „wewnętrznie”: zamiast być wysyłane przez sieć, jest trasowane, wysyłane i obsługiwane przez samą strukturę. Podobieństwo nazw „HMVC” i „MVC” jest mylące, ponieważ sugeruje podstawowy związek między terminami, które w rzeczywistości nie istnieją: jedno nie jest pomniejszą odmianą lub modyfikacją drugiego, są to zupełnie różne rzeczy. (HMVC jest również opisywany jako Ajax bez żądania HTTP po stronie klienta). Nacisk Kohany na „HMVC” i wsparcie dla niego oznacza, że ​​struktura ma silne wsparcie dla architektury zorientowanej na usługi opartej na protokole HTTP.

Zaletą tego wzorca architektonicznego jest to, że ponieważ ta sama „konwencja wywoływania” jest używana dla żądań wewnętrznych i zewnętrznych, konwersja „wewnętrznych” żądań usług na żądania „zewnętrzne” lub odwrotnie, gdy zajdzie taka potrzeba, jest trywialna.

Chociaż jest to rozsądny wzorzec architektoniczny, nadawanie mu własnej nazwy wydaje się niepotrzebne (Symfony2 opisuje tę samą koncepcję „ żądania podrzędne ”). W rzeczywistości nazwa wydaje się być myląca: nie ma żadnego szczególnego wymagania ani potrzeby, aby żądania tworzyły hierarchia (inna niż standardowy wykres wywołań każdego programu imperatywnego); na przykład żądania mogą być łatwo rekurencyjne.

[ Aktualizacja, kwiecień 2011 r., Marzec 2012 r .: rozszerzone w odpowiedzi na komentarze.]

HMVC to hierarchiczny kontroler widoku modelu W normalnym MVC każdy obiekt GUI ma swoje MVC, ale nie ma żadnego związku między nadrzędnym obiektem GUI a obiektem podrzędnego GUI w przeciwieństwie do HMVC. W HMVC każdy obiekt GUI ma dostęp do swoich obiektów podrzędnych, a każdy obiekt podrzędny ma dostęp do swojego obiektu nadrzędnego.

Tak więc w każdym widoku jest widok nadrzędny, przez który może uzyskać dostęp do widoku nadrzędnego. Ponieważ w każdym kontrolerze znajduje się kontroler nadrzędny, przez który może przekazać zdarzenie do kontrolera nadrzędnego (jeśli zdarzenie nie znajduje się w jego zakresie).

Aby uzyskać szczegółowy opis, kliknij tutaj

Nowy link to ten adres