Co to są MVP i MVC i jaka jest różnica?

Spoglądając poza sposób tworzenia interfejsów użytkownika za pomocą RAD (przeciągnij i upuść i skonfiguruj), wiele narzędzi zachęca do natknięcia się na trzy wzorce projektowe o nazwie Model-View-Controller , Model-View-Presenter i Model-View-ViewModel . Moje pytanie składa się z trzech części:

1. Jakie problemy rozwiązują te wzorce?
2. Jak są podobne?
3. Czym się różnią?

Model-View-Presenter

W MVP Prezenter zawiera logikę biznesową interfejsu użytkownika dla widoku. Wszystkie wywołania z widoku delegują bezpośrednio do prezentera. Prezenter jest również odłączony bezpośrednio od Widoku i rozmawia z nim przez interfejs. Ma to na celu umożliwienie kpienia z widoku w teście jednostkowym. Wspólną cechą MVP jest to, że musi być dużo dwukierunkowej wysyłki. Na przykład, gdy ktoś kliknie przycisk „Zapisz”, moduł obsługi zdarzeń przekazuje metodę „OnSave” prezentera. Po zakończeniu zapisywania Prezenter oddzwoni do widoku przez interfejs, aby widok mógł wyświetlić zakończenie zapisywania.

MVP wydaje się być bardzo naturalnym wzorem do uzyskania oddzielnej prezentacji w formularzach internetowych. Powodem jest to, że widok jest zawsze tworzony najpierw przez środowisko wykonawcze ASP.NET. Możesz dowiedzieć się więcej o obu wariantach .

Dwie podstawowe odmiany

Widok pasywny: Widok jest tak głupi, jak to możliwe i zawiera prawie zerową logikę. Prezenter to środkowy człowiek, który rozmawia z widokiem i modelem. Widok i model są całkowicie chronione przed sobą. Model może wywoływać zdarzenia, ale Prezenter subskrybuje je w celu aktualizacji Widoku. W widoku pasywnym nie ma bezpośredniego powiązania danych, zamiast tego widok pokazuje właściwości ustawiające, których Prezenter używa do ustawiania danych. Wszystkim stanem zarządza Prezenter, a nie Widok.

• Pro: maksymalna powierzchnia testowalności; czyste oddzielenie widoku i modelu
• Przeciw: więcej pracy (na przykład wszystkie właściwości ustawiające), ponieważ samodzielnie wykonujesz wszystkie dane.

Kontroler nadzorujący: Prezenter obsługuje gesty użytkownika. Widok wiąże się z modelem bezpośrednio przez powiązanie danych. W tym przypadku zadaniem Prezentera jest przekazanie Modelu do Widoku, aby mógł się z nim połączyć. Prezenter będzie również zawierał logikę gestów, takich jak naciśnięcie przycisku, nawigacja itp.

• Pro: dzięki wykorzystaniu wiązania danych ilość kodu jest zmniejszona.
• Przeciw: jest mniej testowalnej powierzchni (z powodu powiązania danych) i jest mniej enkapsulacji w Widoku, ponieważ mówi on bezpośrednio do Modelu.

Model-View-Controller

W MVC kontroler jest odpowiedzialny za określenie, który widok ma być wyświetlany w odpowiedzi na dowolne działanie, w tym także podczas ładowania aplikacji. Różni się to od MVP, gdzie działania kierują się przez Widok do Prezentera. W MVC każda akcja w Widoku koreluje z wywołaniem do Kontrolera wraz z akcją. W sieci każde działanie wiąże się z wywołaniem adresu URL po drugiej stronie, na który odpowiada Administrator. Po zakończeniu przetwarzania kontroler zwróci prawidłowy widok. Sekwencja trwa w ten sposób przez cały okres użytkowania aplikacji:

    Działanie w widoku
        -> Zadzwoń do kontrolera
        -> Logika sterownika
        -> Kontroler zwraca widok.

Inną dużą różnicą dotyczącą MVC jest to, że widok nie wiąże się bezpośrednio z modelem. Widok po prostu renderuje i jest całkowicie bezstanowy. W implementacjach MVC View zwykle nie ma logiki w kodzie. Jest to sprzeczne z MVP, gdzie jest to absolutnie konieczne, ponieważ jeśli Widok nie zostanie przekazany Prezenterowi, nigdy nie zostanie wywołany.

Model prezentacji

Innym wzorcem do obejrzenia jest Model prezentacjiwzór. W tym wzorze nie ma Prezentera. Zamiast tego widok wiąże się bezpośrednio z modelem prezentacji. Model prezentacji jest modelem stworzonym specjalnie dla Widoku. Oznacza to, że ten model może ujawniać właściwości, których nigdy nie postawiłby na model domeny, ponieważ byłoby to naruszeniem separacji obaw. W takim przypadku Model prezentacji wiąże się z modelem domeny i może subskrybować zdarzenia pochodzące z tego modelu. Widok następnie subskrybuje wydarzenia pochodzące z modelu prezentacji i odpowiednio się aktualizuje. Model prezentacji może ujawniać polecenia, których widok używa do wywoływania akcji. Zaletą tego podejścia jest to, że można w zasadzie całkowicie usunąć kod z tyłu, ponieważ PM całkowicie obudowuje całe zachowanie widoku.Model-View-ViewModel .

Istnieje artykuł MSDN na temat Modelu prezentacji i sekcja w Wytycznych dla aplikacji złożonych dla WPF (dawny Pryzmat) na temat Oddzielnych Wzorów Prezentacji

Jest to nadmierne uproszczenie wielu wariantów tych wzorów projektowych, ale tak lubię myśleć o różnicach między nimi.

MVC

MVP

Pisałem o tym na blogu jakiś czas temu, cytując znakomity post Todda Snydera na temat różnicy między nimi :

Oto kluczowe różnice między wzorami:

Wzór MVP

• Widok jest luźniej sprzężony z modelem. Prezenter jest odpowiedzialny za powiązanie modelu z widokiem.
• Łatwiejszy do testu jednostkowego, ponieważ interakcja z widokiem odbywa się za pośrednictwem interfejsu
• Zwykle wyświetl mapę prezentera jeden do jednego. Złożone widoki mogą mieć wielu prezenterów.

Wzór MVC

• Kontroler opiera się na zachowaniach i może być dzielony między widokami
• Może być odpowiedzialny za określenie, który widok ma zostać wyświetlony

To najlepsze wyjaśnienie w sieci, jakie udało mi się znaleźć.

Oto ilustracje przedstawiające przepływ komunikacji

MVP to nie koniecznie scenariusz gdzie widok jest odpowiedzialny za (patrz MVP Taligent dla przykładu).
Uważam za niefortunne, że ludzie nadal głoszą to jako wzorzec (Zobacz za), w przeciwieństwie do anty-wzorca, ponieważ zaprzecza on „To tylko widok” (Pragmatic Programmer). „To tylko widok” stwierdza, że ​​ostateczny widok pokazany użytkownikowi jest drugorzędną sprawą aplikacji. Wzorzec MVP firmy Microsoft znacznie utrudnia ponowne korzystanie z widoków i wygodnie zwalnia projektanta Microsoft od zachęcania do złych praktyk.

Szczerze mówiąc, uważam, że podstawowe obawy MVC są prawdziwe w przypadku każdej implementacji MVP, a różnice są prawie całkowicie semantyczne. Tak długo, jak postępujesz zgodnie z rozdziałem obaw między widokiem (który wyświetla dane), kontrolerem (który inicjuje i kontroluje interakcję użytkownika) i modelem (dane bazowe i / lub usługi), osiągasz korzyści z MVC . Jeśli osiągasz korzyści, to kogo tak naprawdę obchodzi, czy Twój wzór to MVC, MVP czy kontroler nadzorujący? Jedyny prawdziwy wzór pozostaje jako MVC, reszta to tylko różne smaki.

Rozważ ten niezwykle ekscytujący artykuł, który kompleksowo wymienia szereg tych różnych implementacji. Możesz zauważyć, że w zasadzie wszyscy robią to samo, ale nieco inaczej.

Osobiście uważam, że MVP został niedawno ponownie wprowadzony jako chwytliwy termin, aby albo zredukować argumenty między semantycznymi bigotami, którzy spierają się, czy coś jest naprawdę MVC, czy też usprawiedliwić narzędzia Microsofts Rapid Application Development. Żaden z tych powodów w moich książkach nie uzasadnia jego istnienia jako osobnego wzorca projektowego.

MVP: widok jest odpowiedzialny.

Widok w większości przypadków tworzy jego prezentera. Prezenter będzie wchodził w interakcje z modelem i manipulował widokiem poprzez interfejs. Widok czasami wchodzi w interakcję z prezenterem, zwykle przez jakiś interfejs. Sprowadza się to do wdrożenia; czy chcesz, aby widok wywoływał metody prezentera, czy chcesz, aby widok zawierał zdarzenia, których prezenter słucha? Sprowadza się to do tego: widok wie o prezencie. Widok deleguje do prezentera.

MVC: kontroler jest odpowiedzialny.

Kontroler jest tworzony lub dostępny na podstawie jakiegoś zdarzenia / żądania. Kontroler następnie tworzy odpowiedni widok i współdziała z modelem w celu dalszej konfiguracji widoku. Sprowadza się do: kontroler tworzy widok i zarządza nim; widok jest podrzędny dla kontrolera. Widok nie wie o kontrolerze.

MVC (kontroler widoku modelu)

Wejście jest najpierw kierowane do kontrolera, a nie do widoku. Dane wejściowe mogą pochodzić od użytkownika wchodzącego w interakcję ze stroną, ale mogą też pochodzić z wpisania określonego adresu URL w przeglądarce. W obu przypadkach jest to kontroler, który jest połączony z niektórymi funkcjami. Istnieje relacja typu jeden do jednego między kontrolerem a widokiem. Jest tak, ponieważ pojedynczy kontroler może wybrać różne widoki do renderowania w zależności od wykonywanej operacji. Zwróć uwagę na strzałkę w jedną stronę od kontrolera do widoku. Wynika to z faktu, że widok nie ma żadnej wiedzy ani odniesienia do kontrolera. Kontroler przekazuje model z powrotem, więc istnieje wiedza między widokiem a oczekiwanym modelem przekazywanym do niego, ale nie kontroler go obsługuje.

MVP (Prezenter widoków modelu)

Wejście zaczyna się od Widoku, a nie Prezentera. Pomiędzy widokiem i powiązanym prezenterem istnieje mapowanie jeden na jeden. Widok zawiera odniesienie do Prezentera. Prezenter reaguje również na zdarzenia wyzwalane z Widoku, więc jest świadomy Widoku, z którym jest powiązany. Prezenter aktualizuje widok na podstawie żądanych działań, które wykonuje na modelu, ale widok nie obsługuje modelu.

Aby uzyskać więcej Referencje

Istnieje wiele odpowiedzi na to pytanie, ale czułem, że potrzebna jest naprawdę prosta odpowiedź, wyraźnie porównująca oba. Oto dyskusja, którą przygotowałem, gdy użytkownik szuka nazwy filmu w aplikacjach MVP i MVC:

Użytkownik: Kliknij, kliknij…

Zobacz : Kto to jest? [ MVP | MVC ]

Użytkownik: Właśnie kliknąłem przycisk wyszukiwania…

Widok : Ok, poczekaj chwilę… [ MVP | MVC ]

( Zobacz dzwonienie do Prezentera | Kontrolera …) [ MVP | MVC ]

Zobacz : Hej Prezenter | Kontrolerze , użytkownik właśnie kliknął przycisk wyszukiwania, co mam zrobić? [ MVP | MVC ]

Prezenter | Kontroler : Hey Zobacz , czy jest jakiś termin wyszukiwania na tej stronie? [ MVP | MVC ]

Widok : Tak,… tutaj jest… „fortepian” [ MVP | MVC ]

Prezenter : Dzięki Widok ,… tymczasem szukam wyszukiwanego hasła w Modelu , pokaż mu pasek postępu [ MVP | MVC ]

( Prezenter | Kontroler dzwoni do modelu …) [ MVP | MVC ]

Prezenter | Kontroler : Hej, model , czy pasujesz do tego wyszukiwanego hasła ?: „piano” [ MVP | MVC ]

Model : Hej Prezenter | Kontroler , pozwól mi sprawdzić… [ MVP | MVC ]

( Model wykonuje zapytanie do bazy danych filmów…) [ MVP | MVC ]

( Po chwili ... )

-------------- Tutaj MVP i MVC zaczynają się rozchodzić ---------------

Model : Znalazłem dla ciebie listę, Prezenter , oto JSON „[{” name ”:„ Piano Teacher ”,„ year ”: 2001}, {„ name ”:„ Piano ”,„ year ”: 1993} ] ”[ MVP ]

Model : Dostępne są wyniki, Kontroler . Utworzyłem zmienną pola w moim wystąpieniu i wypełniłem ją wynikiem. Nazywa się „searchResultsList” [ MVC ]

( Prezenter | Kontroler dziękuje Modelowi i wraca do Widoku ) [ MVP | MVC ]

Prowadzący : Dziękujemy za czekanie. Zobacz , znalazłem listę pasujących wyników dla Ciebie i uporządkowałem je w możliwym do przedstawienia formacie: [„Piano Teacher 2001”, „Piano 1993”]. Pokaż to użytkownikowi na liście pionowej. Teraz też ukryj pasek postępu [ MVP ]

Kontroler : Dzięki za czekał View , poprosiłem model o zapytaniu. Mówi, że znalazł listę pasujących wyników i zapisał je w zmiennej o nazwie „searchResultsList” wewnątrz swojej instancji. Możesz go zdobyć stamtąd. Teraz też ukryj pasek postępu [ MVC ]

Zobacz : Bardzo dziękuję Prezenterowi [ MVP ]

Widok : Dziękuję „Kontrolerowi” [ MVC ] (Teraz widok sam siebie zadaje pytanie: w jaki sposób mam przedstawić użytkownikowi wyniki uzyskane z modelu ? Czy rok produkcji filmu powinien być pierwszy czy ostatni…? być na liście pionowej lub poziomej? ...)

Jeśli jesteś zainteresowany, piszę serię artykułów dotyczących wzorców architektonicznych aplikacji (MVC, MVP, MVVP, czystej architektury, ...) wraz z repozytorium Github tutaj . Mimo że próbka została napisana dla Androida, podstawowe zasady można zastosować do dowolnego medium.

• MVP = Model-View-Presenter

• MVC = Model-View-Controller

  1. Oba wzorce prezentacji. Rozdzielają zależności między modelem (obiekty domeny Think), ekranem / stroną internetową (widok), a tym, jak powinien zachowywać się interfejs użytkownika (prezenter / kontroler)
  2. Są dość podobne w koncepcji, ludzie inicjują Prezentera / Kontrolera inaczej w zależności od gustu.
  3. Świetny artykuł na temat różnic jest tutaj . Najbardziej godne uwagi jest to, że wzorzec MVC ma model aktualizujący widok.

Model-View-Controller

MVC jest wzorem dla architektury aplikacji. Dzieli logikę aplikacji na trzy osobne części, promując modułowość oraz łatwość współpracy i ponownego użycia. Dzięki temu aplikacje są bardziej elastyczne i przyjazne dla iteracji, dzieli aplikację na następujące komponenty:

• Modele do obsługi danych i logiki biznesowej
• Kontrolery do obsługi interfejsu użytkownika i aplikacji
• Widoki do obsługi obiektów i prezentacji graficznego interfejsu użytkownika

Aby to trochę wyjaśnić, wyobraźmy sobie prostą aplikację z listą zakupów. Wszystko czego chcemy to lista nazwy, ilości i ceny każdego produktu, który musimy kupić w tym tygodniu. Poniżej opiszemy, jak możemy zaimplementować niektóre z tych funkcji za pomocą MVC.

Model-View-Presenter

• Modelu są dane, które będą wyświetlane w widoku (interfejsu użytkownika).
• Widok jest interfejs, który wyświetla dane (model) i polecenia trasy użytkownika (events), prezenter działać na tych danych. Widok zwykle ma odniesienie do swojego Prezentera.
• Presenter jest „middle-man” (grany przez kontrolera w MVC) i ma odniesienia do obu, widok i modelu. Pamiętaj, że słowo „model” wprowadza w błąd. Powinna to być logika biznesowa, która pobiera lub manipuluje modelem . Na przykład: jeśli masz bazę danych przechowującą użytkownika w tabeli bazy danych, a twój widok chce wyświetlić listę użytkowników, wówczas prezenter będzie miał odniesienie do logiki biznesowej bazy danych (np. DAO), z której prezenter będzie wyszukiwał listę użytkowników.

Jeśli chcesz zobaczyć próbkę z prostą implementacją, sprawdź ten post na GitHub

Konkretny obieg zapytań i wyświetlania listy użytkowników z bazy danych mógłby wyglądać następująco:

Jaka jest różnica między wzorcami MVC i MVP ?

Wzór MVC

• Kontroler opiera się na zachowaniach i może być dzielony między widokami

• Może być odpowiedzialny za określenie, który widok ma zostać wyświetlony (wzór kontrolera przedniego)

Wzór MVP

• Widok jest luźniej sprzężony z modelem. Prezenter jest odpowiedzialny za powiązanie modelu z widokiem.

• Łatwiejszy do testu jednostkowego, ponieważ interakcja z widokiem odbywa się za pośrednictwem interfejsu

• Zwykle wyświetl mapę prezentera jeden do jednego. Złożone widoki mogą mieć wielu prezenterów.

Warto również pamiętać, że istnieją również różne typy MVP. Fowler podzielił wzór na dwie części - widok pasywny i kontroler nadzorujący.

Podczas korzystania z widoku pasywnego widok zwykle implementuje precyzyjny interfejs z właściwościami mapującymi mniej więcej bezpośrednio na widget interfejsu użytkownika. Na przykład możesz mieć ICustomerView z właściwościami takimi jak Nazwa i Adres.

Twoja implementacja może wyglądać mniej więcej tak:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Twoja klasa Presenter będzie rozmawiać z modelem i „mapować” go do widoku. Takie podejście nazywa się „widokiem pasywnym”. Korzyścią jest to, że widok jest łatwy do przetestowania i łatwiejsze jest przemieszczanie się między platformami interfejsu użytkownika (internet, Windows / XAML itp.). Wadą jest to, że nie można korzystać z takich funkcji, jak wiązanie danych (co jest naprawdę potężne w ramach takich jak WPF i Silverlight ).

Drugi smak MVP to kontroler nadzorujący. W takim przypadku Twój Widok może mieć właściwość o nazwie Klient, która następnie jest połączona z widgetami interfejsu użytkownika. Nie musisz myśleć o synchronizacji i mikro-zarządzaniu widokiem, a kontroler nadzorujący może wkroczyć i pomóc w razie potrzeby, na przykład przy skompletowanej logice interakcji.

Trzecim „smakiem” MVP (lub ktoś może nazwałby to odrębnym wzorem) jest Model prezentacji (lub czasami określany jako Model-View-ViewModel). W porównaniu do MVP „scalasz” M i P w jedną klasę. Masz obiekt klienta, do którego powiązane są widżety interfejsu użytkownika, ale masz także dodatkowe pola specyficzne dla interfejsu użytkownika, takie jak „IsButtonEnabled” lub „IsReadOnly” itp.

Myślę, że najlepszym zasobem, jaki znalazłem w architekturze interfejsu użytkownika, jest seria postów na blogu napisanych przez Jeremy'ego Millera w The Build Your Own CAB Series Spis treści . Omówił wszystkie smaki MVP i pokazał kod C #, aby je zaimplementować.

Napisałem także na blogu o wzorcu Model-View-ViewModel w kontekście Silverlight na YouCard. Odwiedziłem ponownie: Implementowanie wzoru ViewModel .

Każdy z nich rozwiązuje różne problemy, a nawet można je łączyć, aby uzyskać coś takiego jak poniżej

Istnieje również pełne porównanie MVC, MVP i MVVM tutaj

Oba te frameworki mają na celu oddzielne obawy - na przykład interakcję ze źródłem danych (model), logikę aplikacji (lub przekształcenie tych danych w przydatne informacje) (kontroler / prezenter) i wyświetlanie kodu (widok). W niektórych przypadkach model można również wykorzystać do przekształcenia źródła danych w abstrakcję wyższego poziomu. Dobrym tego przykładem jest projekt MVC Storefront .

Jest dyskusja tutaj dotyczące różnic między MVC vs MVP.

Rozróżnia się to, że w aplikacji MVC tradycyjnie ma widok, a kontroler wchodzi w interakcję z modelem, ale nie ze sobą.

Projekty MVP umożliwiają Prezenterowi dostęp do modelu i interakcję z widokiem.

Powiedziawszy to, ASP.NET MVC jest według tych definicji strukturą MVP, ponieważ kontroler uzyskuje dostęp do modelu w celu wypełnienia widoku, który ma nie mieć logiki (wyświetla tylko zmienne dostarczone przez kontroler).

Aby dowiedzieć się, czym jest ASP.NET MVC od MVP, zapoznaj się z prezentacją MIX autorstwa Scotta Hanselmana.

Oba wzorce próbują oddzielić logikę prezentacji od logiki biznesowej, oddzielając logikę biznesową od aspektów interfejsu użytkownika

Architektonicznie MVP jest podejściem opartym na kontrolerach stron, gdzie MVC jest podejściem opartym na kontrolerze frontowym. Oznacza to, że w standardowym formularzu MVP cykl życia strony jest po prostu wydłużony poprzez wyodrębnienie logiki biznesowej z kodu za nią. Innymi słowy, strona obsługuje żądanie HTTP. Innymi słowy, MVP IMHO jest ewolucyjnym typem ulepszeń w sieci. Z drugiej strony MVC całkowicie zmienia grę, ponieważ żądanie jest przechwytywane przez klasę kontrolera przed załadowaniem strony, logika biznesowa jest tam wykonywana, a następnie na końcu wyniku przetwarzania danych po prostu zrzuconych na stronę („widok”) W tym sens, MVC wygląda (przynajmniej dla mnie) bardzo na smak kontrolera nadzorującego MVP wzbogaconego o silnik routingu

Oba włączają TDD i mają wady i zalety.

Decyzja o wyborze jednego z nich IMHO powinna opierać się na tym, ile czasu zainwestowano w formę sieci web typu ASPNET. Jeśli ktoś uważa się za dobry w formularzach internetowych, sugerowałbym MVP. Jeśli ktoś nie czułby się tak swobodnie w takich rzeczach, jak cykl życia strony itp. MVC może być dobrym rozwiązaniem.

Oto kolejny link do posta na blogu, podający nieco więcej szczegółów na ten temat

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Użyłem zarówno MVP, jak i MVC i chociaż jako programiści skupiamy się na technicznych różnicach obu wzorców, to punkt MVP w IMHO jest znacznie bardziej związany z łatwością adaptacji niż czymkolwiek innym.

Jeśli pracuję w zespole, który już jako dobry podkład w stylu tworzenia formularzy internetowych, o wiele łatwiej jest wprowadzić MVP niż MVC. Powiedziałbym, że MVP w tym scenariuszu jest szybkim zwycięstwem.

Moje doświadczenie mówi mi, że przenoszenie zespołu z formularzy internetowych do MVP, a następnie z MVP do MVC jest stosunkowo łatwe; przejście z formularzy internetowych do MVC jest trudniejsze.

Zostawiam tutaj link do serii artykułów opublikowanych przez mojego znajomego na temat MVP i MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

W MVP widok pobiera dane z prezentera, który rysuje i przygotowuje / normalizuje dane z modelu, podczas gdy w MVC kontroler pobiera dane z modelu i zestawu, wciskając widok.

W MVP możesz mieć jeden widok działający z wieloma typami prezenterów i jeden prezenter pracujący z różnymi wieloma widokami.

MVP zwykle używa pewnego rodzaju struktury powiązania, takiej jak struktura powiązania Microsoft WPF lub różne struktury powiązania dla HTML5 i Java.

W tych ramach interfejs użytkownika / HTML5 / XAML jest świadomy tego, jaką właściwość prezentera wyświetla każdy element interfejsu użytkownika, więc po powiązaniu widoku z prezenterem widok szuka właściwości i wie, jak z nich wyciągnąć dane oraz w jaki sposób aby je ustawić, gdy użytkownik zmieni wartość w interfejsie użytkownika.

Tak więc, jeśli na przykład model jest samochodem, prezenter jest jakimś prezenterem samochodowym, eksponuje właściwości samochodu (rok, producent, siedzenia itp.). Widok wie, że pole tekstowe o nazwie „producent samochodów” musi wyświetlać właściwość Maker prezentera.

Następnie możesz powiązać z widokiem wiele różnych typów prezenterów, wszystkie muszą mieć właściwość Maker - może to być samolot, pociąg lub cokolwiek innego, widok nie ma znaczenia. Widok pobiera dane z prezentera - bez względu na to, które - o ile implementuje uzgodniony interfejs.

Ta struktura wiązania, jeśli ją rozebrzesz, to tak naprawdę kontroler :-)

I tak, możesz spojrzeć na MVP jako ewolucję MVC.

MVC jest świetny, ale problem polega na tym, że zwykle jego kontroler na widok. Kontroler A wie, jak ustawić pola widoku A. Jeśli teraz chcesz, aby widok A wyświetlał dane modelu B, potrzebujesz kontrolera A, aby znać model B, lub potrzebujesz kontrolera A, aby otrzymać obiekt z interfejsem - który jest podobny MVP tylko bez powiązań lub trzeba przepisać kod zestawu interfejsu użytkownika w kontrolerze B.

Wniosek - zarówno MVP, jak i MVC są oddzielonymi wzorami interfejsu użytkownika, ale MVP zwykle używa struktury powiązań, pod którą znajduje się MVC. THUS MVP znajduje się na wyższym poziomie architektonicznym niż MVC, a wzór owinięcia powyżej MVC.

Mój skromny krótki widok: MVP jest dla dużych skal, a MVC dla małych skal. W przypadku MVC czasami czuję, że V i C mogą być postrzegane jako dwie strony pojedynczego niepodzielnego komponentu, raczej bezpośrednio związane z M, i jedna nieuchronnie do tego dochodzi, gdy przechodzę do krótszych skal, takich jak kontrolki interfejsu użytkownika i podstawowe widżety. Na tym poziomie szczegółowości MVP nie ma większego sensu. Gdy przeciwnie, przechodzimy na większe skale, właściwy interfejs staje się ważniejszy, to samo z jednoznacznym przypisaniem obowiązków, i oto nadchodzi MVP.

Z drugiej strony, ta kciukowa reguła skali może mieć niewielką wagę, gdy cechy platformy sprzyjają pewnego rodzaju relacjom między komponentami, na przykład z siecią, gdzie wydaje się łatwiejsze do wdrożenia MVC, niż MVP.

Myślę, że ten obraz Erwina Vandervalka (i towarzyszący mu artykuł ) jest najlepszym wyjaśnieniem MVC, MVP i MVVM, ich podobieństw i różnic. Artykule nie pojawia się w wynikach wyszukiwania dla zapytania o „MVC, MVP i MVVM”, ponieważ tytuł artykułu nie zawiera słowa „MVC” i „MVP”; ale myślę, że to najlepsze wytłumaczenie.

( Artykuł pasuje również do tego, co powiedział wujek Bob Martin w jednym ze swoich wystąpień: że MVC został pierwotnie zaprojektowany dla małych elementów interfejsu użytkownika, a nie dla architektury systemu)

Istnieje wiele wersji MVC, ta odpowiedź dotyczy oryginalnego MVC w Smalltalk. W skrócie tak jest

Ta rozmowa droidcon NYC 2017 - Clean aplikacja konstrukcja z architekturą Components wyjaśnia go

Jest to fajne wideo od wuja Boba, w którym krótko wyjaśnia MVC i MVP na końcu.

IMO, MVP to ulepszona wersja MVC, w której zasadniczo oddzielasz troskę o to, co pokażesz (dane) od tego, jak pokażesz (widok). Prezenter zawiera logikę biznesową interfejsu użytkownika, domyślnie narzuca dane, które powinny być prezentowane, i podaje listę modeli niemych widoków. A kiedy nadejdzie czas na wyświetlenie danych, po prostu podłączasz widok (prawdopodobnie zawiera te same identyfikatory) do adaptera i ustawiasz odpowiednie pola widoku za pomocą tych modeli widoków z minimalną ilością kodu wprowadzanego (tylko za pomocą ustawiaczy). Jego główną zaletą jest to, że możesz przetestować logikę biznesową interfejsu użytkownika na wiele różnych widoków, takich jak wyświetlanie pozycji na liście poziomej lub liście pionowej.

W MVC rozmawiamy przez interfejsy (granice), aby skleić różne warstwy. Kontroler jest wtyczką do naszej architektury, ale nie ma takiego ograniczenia, aby narzucać to, co pokazać. W tym sensie MVP jest rodzajem MVC z koncepcją widoków podłączanych do kontrolera przez adaptery.

Mam nadzieję, że to pomaga lepiej.

Zapomniałeś o Action-Domain-Responder ( ADR ).

Jak wyjaśniono w niektórych ilustracjach powyżej, istnieje bezpośredni związek / połączenie między modelem a widokiem w MVC. Na kontrolerze wykonywana jest akcja, która wykona akcję na modelu . Że działania w Modelu , wywoła reakcję w widoku . View , jest zawsze na bieżąco, gdy model stan „s zmienia.

Niektórzy zapominają, że MVC powstało pod koniec lat 70-tych , a sieć została stworzona dopiero pod koniec 80" / na początku 90 ". MVC nie zostało pierwotnie utworzone dla Internetu, ale dla aplikacji komputerowych, w których Kontroler Model i widok współistnieją razem.

Ponieważ używamy frameworków internetowych ( np .: Laravel ), które wciąż używają tych samych konwencji nazewnictwa ( model-view-controller ), mamy tendencję do myślenia, że ​​musi to być MVC, ale w rzeczywistości jest to coś innego.

Zamiast tego spójrz na Action-Domain-Responder . W ADR kontroler otrzymuje akcję , która wykona operację w modelu / domenie . Jak dotąd to samo. Różnica polega na tym, że następnie zbiera odpowiedź / dane tej operacji i przekazuje ją do obiektu odpowiadającego ( np.:) Wview() celu renderowania. Gdy wymagane jest nowe działanie na tym samym komponencie, kontroler jest ponownie wywoływany, a cykl się powtarza. W ADR nie ma związku między modelem / domeną a widokiem ( odpowiedź reponsera ).

Uwaga: Wikipedia stwierdza, że ​​„ Każde działanie ADR jest jednak reprezentowane przez osobne klasy lub zamknięcia ”. To nie jest musi być prawdą. Kilka akcji może być w tym samym kontrolerze, a wzorzec jest nadal taki sam.

mvc adr kontroler widoku modelu obiekt reagujący na działanie

Najprostszą odpowiedzią jest interakcja widoku z modelem. W MVP widok jest aktualizowany przez prezentera, który działa jako pośrednik między widokiem a modelem. Prezenter pobiera dane wejściowe z widoku, który pobiera dane z modelu, a następnie wykonuje dowolną wymaganą logikę biznesową, a następnie aktualizuje widok. W MVC model aktualizuje widok bezpośrednio, zamiast wracać do kontrolera.

• W MVC View ma część interfejsu użytkownika, kontroler jest mediatorem między widokiem a modelem, a model zawiera logikę biznesową.
• W MVP View zawiera zarówno interfejs użytkownika, jak i implementację prezentera, ponieważ tutaj prezenter jest tylko interfejsem, a model jest taki sam, tzn. Zawiera logikę biznesową.

MVP

MVP oznacza Model - View-Presenter. Tak stało się na początku 2007 r., Kiedy Microsoft wprowadził aplikacje Windows Smart Client.

Prezenter pełni rolę nadzorczą w MVP, która wiąże zdarzenia i logikę biznesową z modeli.

Powiązanie zdarzenia widoku zostanie zaimplementowane w prezencie z interfejsu widoku.

Widok jest inicjatorem wprowadzania danych przez użytkownika, a następnie deleguje zdarzenia do Prezentera, a prezenter obsługuje powiązania zdarzeń i pobiera dane z modeli.

Plusy: widok ma tylko interfejs użytkownika, a nie logikę. Wysoki poziom testowalności

Wady: nieco skomplikowane i więcej pracy przy wdrażaniu powiązań zdarzeń

MVC

MVC oznacza Model-View-Controller. Kontroler jest odpowiedzialny za tworzenie modeli i renderowanie widoków z powiązanymi modelami.

Kontroler jest inicjatorem i decyduje, który widok ma być renderowany.

Plusy: Nacisk na zasadę pojedynczej odpowiedzialności Wysoki poziom testowalności

Wady: Czasami zbyt duże obciążenie kontrolerów, jeśli próbują renderować wiele widoków w tym samym kontrolerze.