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:
- Jakie problemy rozwiązują te wzorce?
- Jak są podobne?
- Czym się różnią?
design-patterns
model-view-controller
user-interface
mvp
glossary
Mike Minutillo
źródło
źródło
Odpowiedzi:
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.
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.
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:
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
źródło
MVC
często jest używany przez takie środowiska internetowe, jak np.Laravel
Gdzie otrzymane żądania URL (być może tworzone przez użytkowników) są obsługiwane przezController
i HTML generowany przezView
jest wysyłany do klienta - więcView
jest 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ę toMVP
(jak wAndroid
systemie operacyjnym), gdzieactions route through the View to the Presenter
i użytkownik ma bezpośredni dostęp doView
.Jest to nadmierne uproszczenie wielu wariantów tych wzorów projektowych, ale tak lubię myśleć o różnicach między nimi.
MVC
MVP
źródło
Pisałem o tym na blogu jakiś czas temu, cytując znakomity post Todda Snydera na temat różnicy między nimi :
To najlepsze wyjaśnienie w sieci, jakie udało mi się znaleźć.
źródło
Oto ilustracje przedstawiające przepływ komunikacji
źródło
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.
źródło
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.
źródło
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
źródło
MVP
wzorcu, 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?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.
źródło
MVC = Model-View-Controller
źródło
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:
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
Konkretny obieg zapytań i wyświetlania listy użytkowników z bazy danych mógłby wyglądać następująco:
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.
źródło
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:
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 .
źródło
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
źródło
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.
źródło
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
źródło
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
źródło
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.
źródło
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.
źródło
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)
źródło
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
źródło
UIKit
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.
źródło
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.:) W
view()
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
źródło
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.
źródło
źródło
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.
źródło