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

2133

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ą?
Mike Minutillo
źródło
4
mvc.givan.se/#mvp
givanse
2
IDK, ale podobno do oryginalnego MVC, miał być używany w małych. Każdy przycisk, etykieta itp. Miał własny widok i obiekt kontrolera, a przynajmniej tak twierdzi wujek Bob. Myślę, że mówił o Smalltalk. Spójrz na jego rozmowy na YouTube, są fascynujące.
still_dreaming_1
MVP dodaje dodatkową warstwę pośrednictwa, dzieląc kontroler widoku na widok i prezentera ...
the_prole
2
Główną różnicą jest to, że w MVC kontroler nie przekazuje żadnych danych z modelu do widoku. Po prostu powiadamia widok, aby pobrać dane z samego modelu. Jednak w MVP nie ma połączenia między widokiem a modelem. Sam prezenter pobiera dane potrzebne z modelu i przekazuje je do widoku, aby je wyświetlić. Więcej na ten temat wraz z próbką Androida we wszystkich wzorach architektury można znaleźć tutaj: digigene.com/category/android/android-architecture
Ali Nem
Nazywa się je wzorami architektonicznymi, a nie wzorami projektowymi . Jeśli chcesz poznać różnicę, sprawdź to
Hasan El-Hefnawy

Odpowiedzi:

1996

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

Glenn Block
źródło
27
Czy możesz wyjaśnić to zdanie? 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ą. Dla mnie to brzmi tak samo, ale jestem pewien, że opisujesz coś innego.
Panzercrisis,
16
@Panzercrisis Nie jestem pewien, czy to miał na myśli autor, ale myślę, że to właśnie chcieli powiedzieć. Podobnie jak ta odpowiedź - wspomina stackoverflow.com/a/2068/74556 , w MVC metody kontrolera są oparte na zachowaniach - innymi słowy, można odwzorować wiele widoków (ale to samo zachowanie) na pojedynczy kontroler. W MVP prezenter jest sprzężony bliżej widoku i zwykle skutkuje mapowaniem, które jest bliższe jeden do jednego, tj. Akcja podglądu mapuje na odpowiadającą mu metodę prezentera. Zwykle nie odwzorowuje się działań innego widoku na metodę innego prezentera (z innego widoku).
Dustin Kendall
2
Zauważ, że MVC często jest używany przez takie środowiska internetowe, jak np. LaravelGdzie otrzymane żądania URL (być może tworzone przez użytkowników) są obsługiwane przez Controlleri HTML generowany przez Viewjest wysyłany do klienta - więc Viewjest to część backendu i użytkownik nigdy nie może uzyskać do niego bezpośredniego dostępu, a jeśli zauważysz coś przeciwnego, rozważ to jako rozszerzenie MVC (a nawet naruszenie). @Panzercrisis, Różni się to MVP(jak w Androidsystemie operacyjnym), gdzie actions route through the View to the Presenteri użytkownik ma bezpośredni dostęp do View.
Top-Master,
454

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

MVC

MVC

MVP

wprowadź opis zdjęcia tutaj

Phyxx
źródło
10
Jest to świetne przedstawienie schematu, pokazujące abstrakcję i całkowitą izolację dowolnego interfejsu GUI (zobacz rzeczy) od API prezentera. Jedna drobna uwaga: główny prezenter może być używany tam, gdzie jest tylko jeden prezenter, a nie jeden na widok, ale twój schemat jest najczystszy. IMO, największa różnica między MVC / MVP polega na tym, że MVP stara się utrzymać widok całkowicie pozbawiony jakichkolwiek elementów poza wyświetlaniem bieżącego „stanu widoku” (dane danych), jednocześnie uniemożliwiając widok jakiejkolwiek wiedzy o obiektach Modelu. Zatem interfejsy, które muszą tam być, aby wprowadzić ten stan.
4
Dobre zdjęcie. Używam MVP dość często, więc chciałbym podkreślić jedną rzecz. Z mojego doświadczenia wynika, że ​​Prezenterzy muszą często ze sobą rozmawiać. To samo dotyczy modeli (lub obiektów biznesowych). Z powodu tych dodatkowych „niebieskich linii” komunikacji, które byłyby na twoim zdjęciu MVP, relacje między Prezenterem a Modelem mogą się bardzo uwikłać. Dlatego staram się utrzymywać relację jeden-do-jednego Modelu Prezentującego vs. jeden-do-wielu. Tak, wymaga dodatkowych metod delegowania w Modelu, ale zmniejsza wiele problemów głowy, jeśli interfejs API Modelu zmienia się lub wymaga refaktoryzacji.
splungebob
3
Przykład MVC jest błędny; istnieje ścisły związek 1: 1 między widokami a kontrolerami. Z definicji kontroler interpretuje wprowadzanie gestów przez człowieka w celu wygenerowania zdarzeń dla modelu i wyświetlenia podobnego dla pojedynczego elementu sterującego. Mówiąc prościej, MVC był przeznaczony do użytku tylko z poszczególnymi widżetami. Jeden widżet, jeden widok, jedno sterowanie.
Samuel A. Falvo II
3
@ SamuelA.FalvoII nie zawsze istnieje 1: Wiele między kontrolerami i widokami w ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser
4
@StuperUser - Nie jestem pewien, co myślałem, kiedy to napisałem. Oczywiście masz rację i patrząc wstecz na to, co napisałem, muszę się zastanawiać, czy miałem na myśli jakiś inny kontekst, którego nie udało mi się wyrazić. Dziękuję za poprawienie mnie.
Samuel A. Falvo II
421

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źć.

Jon Limjap
źródło
15
Nie rozumiem, w jaki sposób widok może być sprzężony mniej więcej z modelem, gdy w obu przypadkach chodzi o całkowite ich oddzielenie. Nie sugeruję, że powiedziałeś coś złego - po prostu mylę co masz na myśli.
Bill K
18
@pst: z MVP to naprawdę 1 widok = 1 prezenter. Dzięki MVC kontroler może zarządzać wieloma widokami. To jest naprawdę. W modelu „kart” wyobraź sobie, że każda karta ma swojego Prezentera, a nie jeden kontroler dla wszystkich kart.
Jon Limjap
4
Początkowo istnieją dwa typy kontrolerów: ten, o którym mówiono, że jest współużytkowany przez wiele widoków, oraz te, które są specyficzne dla widoków, głównie w celu dostosowania interfejsu kontrolera współdzielonego.
Acsor
1
@JonLimjap Co to właściwie oznacza jeden widok? Czy w kontekście programowania na iOS jest to jedno ekranowe? Czy to sprawia, że ​​kontroler iOS bardziej przypomina MVP niż MVC? (Z drugiej strony możesz również mieć wiele kontrolerów iOS na ekran)
huggie
2
Cóż, schematyczna ilustracja MVC Todda całkowicie przeczy idei oddzielenia widoku i modelu. Jeśli spojrzysz na diagram, wyświetli się Widok aktualizacji modelu (strzałka od modelu do widoku). W którym wszechświecie jest system, w którym Model oddziałuje bezpośrednio z Widokiem, oddzielonym?
Ash
260

Oto ilustracje przedstawiające przepływ komunikacji

wprowadź opis zdjęcia tutaj

wprowadź opis zdjęcia tutaj

Ashraf Bashir
źródło
43
Mam pytanie dotyczące schematu MVC. Nie dostaję części, w której widok wychodzi do pobierania danych. Wydaje mi się, że kontroler prześle widok do potrzebnych danych.
Brian Rizo,
54
Jeśli użytkownik kliknie przycisk, jak to nie wchodzi w interakcję z widokiem? Czuję się jak w MVC, użytkownik bardziej niż kontroler wchodzi w interakcję z widokiem
Jonathan
5
Wiem, że to stara odpowiedź - ale czy ktoś może odpowiedzieć na @JonathanLeaders? Pochodzę z tła WinForm, chyba że wykonałeś bardzo unikalne kodowanie, kiedy klikniesz interfejs użytkownika / Widok uzyskuje wiedzę o tym kliknięciu, zanim cokolwiek innego. Przynajmniej o ile mi wiadomo?
Rob P.
6
@RobP. Myślę, że tego rodzaju wykresy zawsze są albo zbyt skomplikowane, albo zbyt proste. Imo przepływ wykresu MVP odnosi się również do aplikacji MVC. Mogą występować różnice w zależności od funkcji języków (powiązanie danych / obserwator), ale ostatecznie chodzi o oddzielenie widoku od danych / logiki aplikacji.
Luca Fülbier
15
@JonathanLeaders Ludzie mają bardzo różne rzeczy na myśli, gdy mówią „MVC”. Osoba, która utworzyła ten wykres, prawdopodobnie miała na myśli klasyczny Web MVC, w którym „dane wejściowe użytkownika” to żądania HTTP, a „widok zwrócony użytkownikowi” to renderowana strona HTML. Tak więc wszelkie interakcje między użytkownikiem a widokiem „nie istnieją” z perspektywy autora klasycznej aplikacji Web MVC.
cubuspl42
170

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.

Quibblesome
źródło
28
Przeczytałem kilka odpowiedzi i blogów na temat różnic między MVC / MVP / MVVM / etc ”. W rzeczywistości, kiedy zaczynasz interesy, wszystko jest takie samo. Tak naprawdę nie ma znaczenia, czy masz interfejs, czy nie, i czy używasz setera (lub jakiejkolwiek innej funkcji językowej). Wygląda na to, że różnica między tymi wzorcami zrodziła się z różnej implementacji różnych frameworków, a nie z samej koncepcji.
Michael
6
Nie nazwałbym MVP anty-wzorem , ponieważ później w poście „.. reszta [w tym MVP] to po prostu różne smaki [MVC] ..”, co sugerowałoby, że gdyby MVP był anty-wzorem, więc był MVC ... to po prostu smak innego podejścia do frameworka. (Teraz niektóre konkretne implementacje MVP mogą być mniej lub bardziej pożądane niż niektóre konkretne implementacje MVC do różnych zadań ...)
@Quibblsome: „Osobiście uważam, że MVP został niedawno ponownie wprowadzony jako chwytliwy termin, aby albo zmniejszyć argumenty między semantycznymi bigotami, którzy spierają się, czy coś jest naprawdę MVC, czy nie […] Żaden z tych powodów w moich książkach nie uzasadnia jego istnienia jako oddzielny wzór. ” . Różni się na tyle, aby było wyraźne. W MVP widokiem może być wszystko spełniające predefiniowany interfejs (widok w MVP jest samodzielnym komponentem). W MVC kontroler jest stworzony dla konkretnego widoku (jeśli aromaty relacji mogą sprawić, że ktoś poczuje, że jest wart innego terminu).
Hibou57
6
@ Hibou57, nic nie stoi na przeszkodzie, aby MVC odwoływało się do widoku jako interfejsu lub tworzyło ogólny kontroler dla kilku różnych widoków.
Quibblesome
1
Samuel, proszę wyjaśnij, o czym mówisz. O ile nie opowiesz mi historii zespołu, który „wynalazł” MVC, jestem bardzo nieufny co do twojego tekstu. Jeśli mówisz tylko o WinForm, istnieją inne sposoby robienia rzeczy, a ja stworzyłem projekty WinForm, w których kontroler zarządza powiązaniami kontrolnymi, a nie „indywidualnymi kontrolkami”.
Quibblesome
110

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.

Brian Leahy
źródło
3
„Widok nie wie o kontrolerze”. Myślę, że masz na myśli, że widok nie ma bezpośredniego kontaktu z modelem?
Lotus Notes,
2
widok nigdy nie powinien wiedzieć o modelu w innym.
Brian Leahy
4
@Brian: „Widok w większości przypadków tworzy prezentera”. . W większości widziałem coś przeciwnego, gdy Prezenter uruchamiał zarówno Model, jak i Widok. Cóż, Widok może również uruchomić Prezentera, ale ten punkt nie jest tak naprawdę najbardziej charakterystyczny. Najważniejsze dzieje się później w ciągu życia.
Hibou57
2
Możesz zredagować swoją odpowiedź, aby wyjaśnić dalej: Ponieważ widok nie wie o kontrolerze, w jaki sposób działania użytkownika, które są wykonywane na elementach „wizualnych”, które widzi użytkownik na ekranie (tj. Widok), są przekazywane do kontrolera ...
Ash
77

wprowadź opis zdjęcia tutaj

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

AVI
źródło
Ale czy we MVPwzorcu, gdy aplikacja ładuje się po raz pierwszy, czy prezenter nie jest odpowiedzialny za załadowanie pierwszego widoku? Na przykład, gdy ładujemy aplikację Facebook, czy prezenter nie jest odpowiedzialny za załadowanie strony logowania?
viper
2
Link z modelu do widoku w MVC? Możesz edytować swoją odpowiedź, aby wyjaśnić, w jaki sposób czyni to system „oddzielonym”, biorąc pod uwagę ten link. Wskazówka: może być ci trudno. Ponadto, chyba że uważasz, że czytelnik z radością zaakceptuje fakt, że przez całe życie źle się obliczyli, możesz wyjaśnić, dlaczego działania najpierw przechodzą przez kontroler w MVC, mimo że użytkownik wchodzi w interakcję z elementami „wizualnymi” na ekranie (tj. Widok), a nie jakaś abstrakcyjna warstwa, która stoi za przetwarzaniem.
Ash
2
Jest to wyraźnie błędne ... w MVC model nigdy nie mówi bezpośrednio z widokiem i vice versa. Nie wiedzą nawet, że istnieje inny. Kontroler to klej, który utrzymuje je razem
MegaManX
1
Zgadzam się z Ash i MegaManX. Na schemacie MVC strzałka powinna pochodzić z widoku wskazującego na model (lub ViewModel lub DTO), a nie od modelu do widoku; ponieważ model nie wie o widoku, ale widok może wiedzieć o modelu.
Jboy Flaga
57

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.

Ali Nem
źródło
Zasadniczo próbujesz powiedzieć, że kontroler zarządza logiką widoku? Czyni to widok głupszym, przedstawiając, co się dzieje i jak na widokach?
Radu
@Radu, Nie, nie zarządza, to jest to, co robi prezenter, czyniąc widok pasywnym lub głupim
Ali Nem
4
W odpowiednim MVC widok wywołuje funkcjonalność kontrolera i nasłuchuje zmian danych w modelu. Widok nie pobiera danych z kontrolera, a kontroler NIE powinien wyświetlać widoku, na przykład, wskaźnika ładowania. Właściwe MVC pozwala na zastąpienie części widoku tą, która jest zasadniczo inna. Część widoku zawiera logikę widoku, która zawiera wskaźnik ładowania. Widok wywołuje instrukcje (w kontrolerze), kontroler modyfikuje dane w modelu, a model powiadamia nasłuchujących o zmianach danych, jednym z takich detektorów jest widok.
Tommy Andersen
35
  • 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.
Brett Veenstra
źródło
2
Model aktualizujący VIew. A to wciąż jest system oddzielony?
Ash
34

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.

wprowadź opis zdjęcia tutaj

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: wprowadź opis zdjęcia tutaj

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.

Rahul
źródło
2
nie, nie ma bezpośredniego połączenia między widokiem a modelem w mvc. twój diagram jest błędny.
Özgür
33

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 .

Jonas Follesø
źródło
25

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

Połączony wzór

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

Xiaoguo Ge
źródło
1
Zamiast nadmiernie komplikować, mogłeś odpowiedzieć na pytanie. Dlatego większość z nas tu jest. Szukałem porównania między mvp i mvc i przekierowano mnie tutaj, a mówisz o harmonii tych architektur, która nie jest związana z OP.
Farid
18

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.

Matt Mitchell
źródło
7
MVC i MVP są wzorcami, a nie ramami. Jeśli szczerze myślisz, ten temat dotyczył frameworku .NET, to tak, jakby słyszeć „internet” i myśleć, że chodzi o IE.
tereško
Jestem całkiem pewien, że pytanie znacznie się zmieniło od czasu, kiedy zadawano je w 2008 roku. Dodatkowo, patrząc wstecz na moją odpowiedź (a było to 4 lata temu, więc nie mam większego kontekstu niż ty) powiedziałbym, że zaczynam ogólnie i następnie użyj .NET MVC jako konkretnego przykładu.
Matt Mitchell,
13

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

Nikola Malovic
źródło
9

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

Pedro Santos
źródło
8

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.

James Roeiter
źródło
6

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.

Hibou57
źródło
4

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.

obraz wyjaśniający MVC, MVP i MVVM - autor: Erwin Vandervalk

( 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)

Jboy Flaga
źródło
3

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

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

wprowadź opis zdjęcia tutaj wprowadź opis zdjęcia tutaj

onmyway133
źródło
6
W MVC model nigdy nie jest wywoływany bezpośrednio z widoku
rodi
5
To jest niedokładna odpowiedź. Nie daj się zwieść. jak pisze @rodi, nie ma interakcji między widokiem a modelem.
Shawn Mehan
Obraz MVC jest niedokładny lub w najlepszym przypadku wprowadzający w błąd, proszę nie zwracać uwagi na tę odpowiedź.
Jay
2
@ Jay1b Co według Ciebie jest MVC „poprawne”? Ta odpowiedź dotyczy oryginalnego MVC. Istnieje wiele innych MVC (jak w iOS), które zostały zmienione, aby dostosować się do platformy, powiedzmyUIKit
onmyway133
Co oznaczają strzałki?
problemofficer
3

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.

standardowe
źródło
2
Ważna uwaga od wuja Boba: Pierwotnie wymyślony przez Trygve Reenskaug, MVC było przeznaczone dla każdego widżetu, a nie dla całej formy.
Basil Bourque,
2

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.

Hugo Rafael Azevedo
źródło
2

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.

Clive Jefferies
źródło
Zgłosiłem się negatywnie, ponieważ afaik model nie wie nic o widoku w MVC i nie można go zaktualizować bezpośrednio podczas pisania.
problem oficer
1
Spójrz na MVC na Wikipedii, dokładnie tak to działa.
Clive Jefferies,
1
Czy czytelnikom się to podoba, czy nie, wiele źródeł, które można znaleźć, przeglądając googluje, że w MVC widok subskrybuje aktualizacje modelu. a w niektórych przypadkach może nawet być kontrolerem i dlatego wywołać takie aktualizacje. Jeśli ci się to nie podoba, to narzekaj na te artykuły lub przytaczaj „biblię”, która według ciebie jest jedynym uzasadnionym źródłem, zamiast odrzucać odpowiedzi, które tylko przekazują inne dostępne informacje!
underscore_d
1
Sformułowanie można zdecydowanie ulepszyć, ale prawdą jest, że widok subskrybuje zmiany w modelu w MVC. Model nie musi znać widoku w MVC.
pożarł elysium
dziękuję .. Bardzo mi pomogło
Dvyn Resh
1
  • 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ą.
Chinmai Kulkarni
źródło
-1

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.

marvelTracker
źródło