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

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

MVC

MVP

Pisałem o tym jakiś czas temu, cytując doskonały post Todda Snydera na temat różnicy między tymi dwoma :

Oto najważniejsze różnice między wzory:

MVP wzór

• widok jest luźniej powiązany z modelem. Prezenter jest odpowiedzialny za Związanie modelu z widok.
• łatwiejsze do testu jednostkowego, ponieważ interakcja z widokiem jest przez interfejs
• prezenter map jeden do jednego. Złożone widoki mogą mieć multi prezenterów.

Wzór MVC

• kontrolery są oparte na zachowaniach i mogą być współdzielone między widoki
• może być odpowiedzialny za określenie, który Widok do wyświetlenia

To najlepsze wyjaśnienie w sieci, jakie mogłem znaleźć.

Oto ilustracje przedstawiające przepływ komunikacji

MVP jest a nie koniecznie scenariuszem, w którym rządzi Widok (zobacz na przykład MVP Taligenta).
Uważam za niefortunne, że ludzie nadal głoszą to jako wzorzec (pogląd rządzący) w przeciwieństwie do anty-wzorca, ponieważ zaprzecza on "to tylko pogląd" (pragmatyczny programista). "To tylko widok" stwierdza, że ostateczny widok pokazany użytkownikowi jest drugorzędnym problemem aplikacji. Wzorzec MVP Microsoftu znacznie utrudnia ponowne wykorzystanie widoków i wygodnie wymawia projektantowi Microsoftu zachęcanie do złych praktyk.

Aby być całkowicie szczerym, myślę, że podstawowe obawy MVC są prawdziwe dla każdej implementacji MVP, a różnice są prawie całkowicie semantyczne. Tak długo, jak postępujesz zgodnie z rozdzieleniem obaw między widok (który wyświetla dane), kontroler (który inicjuje i kontroluje interakcję z użytkownikiem) i model (Podstawowe Dane i/lub usługi)), to osiągasz korzyści z MVC. Jeśli osiągasz korzyści, to kogo naprawdę obchodzi, czy Twój wzór jest MVC, MVP czy kontrolerem nadzorującym? Jedyny prawdziwy wzór pozostaje MVC, reszta to tylko różne jego smaki.

Rozważ ten bardzo ekscytujący artykuł, który wyczerpująco wymienia szereg tych różnych implementacji. Możesz zauważyć, że wszystkie zasadniczo robią to samo, ale nieco inaczej.

Ja osobiście uważam, że MVP dopiero niedawno ponownie wprowadzony jako chwytliwy termin, aby zmniejszyć argumenty między semantycznymi bigotami, którzy spierają się, czy coś jest naprawdę MVC, czy nie, lub aby uzasadnić szybkie narzędzia programistyczne Microsoftów. Żaden z tych powodów w moich książkach nie uzasadnia jego istnienia jako odrębnego wzorca projektowego.

MVP: the view is in charge.

Widok w większości przypadków tworzy swój prezenter. Prezenter wchodzi w interakcję z modelem i manipuluje widokiem za pomocą interfejsu. Widok czasami wchodzi w interakcję z prezenterem, zazwyczaj poprzez jakiś interfejs. Sprowadza się to do implementacji; czy chcesz, aby Widok wywoływał metody na prezenterze, czy chcesz, aby Widok miał zdarzenia, które prezenter słucha? Sprowadza się to do tego: Widok wie o prezenterze. Widok delegatów do prezentera.

MVC: kontroler jest odpowiedzialny.

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

MVC (Model View Controller)

Wejście jest skierowane najpierw do kontrolera, a nie do widoku. Dane wejściowe mogą pochodzić od użytkownika wchodzącego w interakcję ze stroną, ale mogą również pochodzić z prostego wprowadzenia określonego adresu url do przeglądarki. W obu przypadkach jest to kontroler, który jest połączony z uruchomieniem niektórych funkcji. Pomiędzy kontrolerem a widokiem istnieje relacja wiele do jednego. Dzieje się tak dlatego, że pojedynczy kontroler może wybrać inny widoki, które mają być renderowane na podstawie wykonywanej operacji. Zwróć uwagę na strzałkę jednokierunkową z kontrolera do widoku. Dzieje się tak, ponieważ widok nie posiada żadnej wiedzy ani odniesienia do kontrolera. Kontroler przekazuje z powrotem Model, więc istnieje wiedza między widokiem a oczekiwanym modelem, który jest do niego przekazywany, ale nie kontroler obsługujący go.

MVP (Model View Presenter)

Wejście zaczyna się od widoku, nie od prezentera. Jest mapowanie jeden do jednego pomiędzy widokiem A powiązanym prezenterem. Widok zawiera odniesienie do prezentera. Prezenter reaguje również na zdarzenia wyzwalane z widoku, więc jest świadomy widoku, z którym jest związany. Prezenter aktualizuje Widok na podstawie żądanych działań wykonywanych w modelu, ale widok nie jest świadomy modelu.

Więcej Reference

Istnieje wiele odpowiedzi na to pytanie, ale czułem, że istnieje potrzeba jakiejś naprawdę prostej odpowiedzi, wyraźnie porównując te dwa. Oto dyskusja, którą wymyśliłem, gdy użytkownik wyszukuje nazwę filmu w aplikacji MVP i MVC:

User: Click click ...

View : Kto to? [MVP|MVC]

User: właśnie kliknąłem w przycisk Szukaj ...

Zobacz : ok, poczekaj chwilę ... . [MVP|MVC]

( View wywołanie prezenter|Kontroler ... ) [MVP|MVC]

View : Hey prezenter|Kontroler , użytkownik właśnie kliknął przycisk wyszukiwania, co mam zrobić? [MVP|MVC]

prezenter|Controller : Hey View , czy na tej stronie jest jakieś Szukane hasło? [MVP|MVC]

View: Yes, ... here it is ... " piano "[MVP|MVC]

prezenter : Dzięki View , ... tymczasem Szukam szukanego wyrażenia na Model , Proszę pokazać mu / jej pasek postępu [MVP|MVC]

( prezenter|Kontroler wywołuje model ... ) [ MVP|MVC]

prezenter|Kontroler : Hej Model, czy masz jakieś dopasowanie do tego szukanego terminu?: "piano "[MVP|MVC]

Model : Hej prezenter|Controller , let me check ... [MVP|MVC]

( Model {[6] } robi zapytanie do bazy filmów...) [MVP|MVC]

( po chwili ... )

-------------- w tym miejscu MVP i MVC zaczynają się od siebie różnić ---------------

Model: znalazłem dla Ciebie listę, prezenter, tutaj jest w JSON "[{"name":"Piano Teacher","year":2001},{"name":"Piano","year": 1993}]" [MVP ]

Model : dostępny jest jakiś wynik, Kontroler. Utworzyłem zmienną pola w mojej instancji i wypełniłem ją wynikiem. Jego nazwa to " searchResultsList "[MVC ]

(prezenter|Kontroler dzięki modelowi i wraca do widoku ) [MVP|MVC]

prezenter : Dzięki za czekanie Zobacz, znalazłem dla Ciebie listę pasujących wyników i ustawiłem je w prezentowany format: ["Piano Teacher 2001", "Piano 1993"]. Pokaż go użytkownikowi na pionowej liście. Również Proszę teraz ukryć pasek postępu [ MVP ]

Controller : Thanks for waiting View , I have asked Model about your search query. Mówi, że znalazł listę pasujących wyników i zapisał je w zmiennej o nazwie "searchResultsList" wewnątrz swojej instancji. Możesz go stamtąd wyciągnąć. Również proszę ukryć pasek postępu teraz [MVC ]

View : Thank you very much prezenter [MVP]

View : Thank you " Controller "[MVC ] (Teraz widok zadaje sobie pytanie: jak przedstawić użytkownikowi wyniki, które otrzymałem z modelu ? Rok produkcji filmu powinien być pierwszy lub ostatni...? Powinien być na liście pionowej czy poziomej? ...)

Jeśli jesteś zainteresowany, piszę serię artykułów dotyczących wzorce architektoniczne aplikacji (MVC, MVP, MVVP, clean architecture,...) wraz z repo Github tutaj. Mimo że próbka jest napisana dla Androida, podstawowe zasady mogą być stosowane do dowolnego medium.

Model-View-Controller

MVC {[2] } jest wzorcem dla architektury aplikacji. Oddziela logikę aplikacji na trzy oddzielne części, promując modułowość i łatwość współpracy i ponownego użycia. Sprawia również, że aplikacje są bardziej elastyczne i przyjazne dla iterations.It oddziela aplikację na następujące komponenty:

• Modele do obsługi danych i logiki biznesowej
• Kontrolery {[2] } do obsługi interfejs użytkownika i aplikacja
• widoki do obsługi obiektów graficznego interfejsu użytkownika i prezentacji

Aby było to trochę bardziej jasne, wyobraźmy sobie prostą aplikację do listy zakupów. Wszystko, czego chcemy, to lista nazwy, ilości i ceny każdego przedmiotu, który musimy kupić w tym tygodniu. Poniżej opiszemy jak możemy zaimplementować niektóre z tych funkcjonalności przy użyciu MVC.

Model-View-Presenter

• The model {[2] } to dane, które będą wyświetlane w widoku (interfejs użytkownika).
• widok jest interfejsem, który wyświetla dane (model) i kieruje polecenia użytkownika (zdarzenia) do prezentera, aby działał na tych danych. Widok zazwyczaj ma odniesienie do swojego prezentera.
• prezenter jest "środkowym człowiekiem" (odtwarzanym przez kontroler w MVC) i ma odniesienia do obu, widoku i modelu. proszę zauważyć, że słowo "Model" jest mylące. Powinno być raczej logika biznesowa, która pobiera lub manipuluje modelem. Na przykład: jeśli masz bazę danych przechowującą użytkownika w tabeli bazy danych i twój widok chce wyświetlić listę użytkowników, wtedy prezenter będzie miał odniesienie do Twojej logiki biznesowej bazy danych (np. DAO), z której prezenter zapyta listę użytkowników.

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

A concrete workflow of querying a Wyświetlanie listy użytkowników z bazy danych może działać tak:

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

Wzór MVC

• Kontrolery są oparte na zachowaniach i mogą być współdzielone między widokami

• Może być odpowiedzialny za określenie, który Widok ma być wyświetlany (Front Controller Pattern)

MVP wzór

• Widok jest luźniej połączony z modelem. Prezenter jest odpowiedzialny za powiązanie modelu z widokiem.

• Łatwiejsze do testowania jednostkowego, ponieważ interakcja z widokiem odbywa się poprzez interfejs

• Zazwyczaj widok do prezentera map jeden do jednego. Złożone widoki mogą mieć wiele prezenterów.

• MVP = Model-View-Presenter

• MVC = Model-View-Controller

  1. oba wzory prezentacji. Oddzielają zależności między modelem( obiektami think Domain), ekranem/stroną internetową (widokiem) i sposobem zachowania interfejsu użytkownika (prezenterem/kontrolerem)
  2. są dość podobne w koncepcji, ludzie inicjalizują prezenter / Kontroler inaczej w zależności od gustu.
  3. świetny artykuł na temat różnic jest tutaj . Najbardziej godne uwagi są ten wzorzec MVC ma Model aktualizujący Widok.

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

Podczas korzystania z widoku pasywnego, Widok zazwyczaj implementuje drobnoziarnisty interfejs z właściwościami mapującymi mniej lub bardziej bezpośrednio do widżetu interfejsu użytkownika. Na przykład możesz mieć przegląd ICustomerView z właściwościami takimi jak nazwa i adres.

Twoja implementacja może wyglądać jak to:

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

Twoja klasa prezentera porozmawia z modelką i "mapuje" ją do widoku. Takie podejście nazywa się "widokiem pasywnym". Zaletą jest to, że widok jest łatwy do przetestowania i łatwiej jest poruszać się między platformami interfejsu użytkownika (Web, Windows / XAML, itp.). Wadą jest to, że nie można wykorzystać takich rzeczy jak databinding (który jest naprawdę potężny w frameworkach takich jak WPF i Silverlight).

Drugim smakiem MVP jest kontroler nadzorujący. W w takim przypadku twój Widok może mieć właściwość o nazwie Klient, która z kolei jest bazą danych do widżetów 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 z skomplikowaną logiką interakcji.

Trzecim "smakiem" MVP (lub ktoś mógłby to nazwać osobnym wzorem) jest model prezentacji (lub czasami określany jako Model-View-ViewModel). W porównaniu do MVP "łączysz" M i P w jedną klasę. Masz obiekt klienta, do którego widżety UI są powiązane z danymi, ale masz również dodatkowe pola UI-spesific, takie jak "IsButtonEnabled", "IsReadOnly", itp.

Myślę, że najlepszym zasobem, jaki znalazłem w architekturze UI, jest seria wpisów na blogu autorstwa Jeremy ' ego Millera na spis treści serii Build Your Own CAB. Omówił wszystkie smaki MVP i pokazał kod C# do ich implementacji.

Pisałem też na blogu o Model-View - wzór ViewModel w kontekście Silverlight nad at YouCard Re-visited: Implementing the ViewModel pattern.

Każdy z nich rozwiązuje różne problemy i może być nawet łączony razem, aby mieć coś takiego jak poniżej

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

Obie te struktury mają na celu oddzielenie problemów - na przykład interakcji ze źródłem danych( modelem), logiki aplikacji (lub przekształcania tych danych w użyteczne informacje) (Kontroler/prezenter) i kodu wyświetlania (Widok). W niektórych przypadkach model może być również użyty do przekształcenia źródła danych w abstrakcję wyższego poziomu. Dobrym tego przykładem jest projekt MVC Storefront .

Istnieje dyskusja tutaj dotycząca różnic między MVC vs MVP.

Rozróżnienie polega na tym, że w aplikacji MVC tradycyjnie widok i kontroler oddziałują 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 przez te definicje frameworkiem MVP, ponieważ kontroler uzyskuje dostęp do modelu, aby wypełnić widok, który ma nie mieć logiki (wyświetla tylko zmienne dostarczone przez Kontroler).

Aby być może zorientować się w ASP.NET wyróżnienie MVC od MVP, zobacz to prezentacja MIX autorstwa Scotta Hanselmana.

Oba są wzorcami próbującymi oddzielić prezentację 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 kontrolerach frontowych. Oznacza to, że w standardowym formularzu MVP cykl życia strony jest po prostu ulepszony poprzez wyodrębnienie logiki biznesowej z kodu. Innymi słowy, strona jest tą obsługującą żądanie http. Innymi słowy, MVP IMHO jest formą ewolucyjną typu enhancement. MVC na inne ręka całkowicie zmienia grę, ponieważ żądanie zostaje przechwycone przez klasę kontrolera przed załadowaniem strony, tam jest wykonywana logika biznesowa, a następnie w końcowym wyniku przetwarzania przez kontroler danych po prostu zrzuconych na stronę ("widok") W tym sensie MVC wygląda (przynajmniej dla mnie) bardzo podobnie do kontrolera MVP enhanced with routing engine

Oba umożliwiają TDD i mają wady i zalety.

Decyzja jak wybrać jeden z nich IMHO powinna być na podstawie tego, ile czasu zainwestowano w tworzenie stron internetowych ASP NET. Jeśli ktoś uważa się za dobrego w formularzach internetowych, proponuję MVP. Jeśli ktoś nie czuje się tak komfortowo w takich rzeczach jak cykl życia strony itp MVC może być sposobem, aby przejść tutaj.

Oto kolejny link do postu 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ż my jako programiści skupiamy się na technicznych różnicach obu wzorców, punkt dla MVP w IMHO jest o wiele bardziej związany z łatwością przyjęcia niż cokolwiek innego.

Jeśli pracuję w zespole, który już jako dobre tło w stylu tworzenia formularzy internetowych jest o wiele łatwiej wprowadzić MVP niż MVC. Powiedziałbym, że MVP w tym scenariuszu to szybka Wygrana.

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

Zostawiam tutaj link do serii artykułów, które mój znajomy opublikował 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 pobiera i przygotowuje / normalizuje dane z modelu, podczas gdy w MVC kontroler pobiera dane z modelu i ustawia przez push w widoku.

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

MVP zwykle używa pewnego rodzaju wiążącego frameworka, takiego jak Microsoft WPF binding framework lub różnych wiążących frameworków dla HTML5 i Javy.

W tych frameworkach UI / HTML5 / XAML jest świadomy, jaką właściwość prezentera wyświetla każdy element interfejsu użytkownika, więc kiedy wiąże się widok z prezenterem, widok szuka właściwości i wie, jak wyciągnąć z nich Dane i jak ustawić je, gdy wartość jest zmieniana w interfejsie użytkownika.

Jeśli więc na przykład model jest samochodem, to prezenter jest jakimś prezenterem samochodowym, eksponuje właściwości Samochodu (Rok, producent, siedzenia itp.) do widoku. Widok wie, że tekst pole o nazwie "car maker" musi wyświetlić właściwość presenter Maker.

Możesz następnie 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 ma to gdzieś. Widok pobiera dane od prezentera - bez względu na to, który z nich - o ile zaimplementuje uzgodniony interfejs.

Ten wiążący framework, jeśli go zdejmiesz, to faktycznie jest to kontroler : -)

I tak można 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 odbierał obiekt z interfejsem - który jest jak MVP tylko bez powiązań, lub musisz przepisać kod zestawu interfejsu w kontrolerze B.

Podsumowanie-MVP i MVC są oddzielone od wzorców UI, ale MVP zwykle używa wiązania framework czyli MVC pod spodem. Tak więc MVP jest na wyższym poziomie architektonicznym niż MVC i wzorzec owijania powyżej MVC.

Mój skromny krótki pogląd: MVP jest dla dużych skal, a MVC dla małych skal. Z MVC, czasami czuję V i C mogą być postrzegane dwie strony jednego niepodzielnego składnika raczej bezpośrednio związane z M, i nieuchronnie spada do tego, gdy idzie w dół‑do krótszych skal, jak UI kontroli i podstawowych widgetów. Na tym poziomie szczegółowości MVP nie ma sensu. Gdy jeden przeciwnie przejść do większej skali, właściwy interfejs staje się ważniejsze, to samo z jednoznacznym przypisaniem obowiązki i nadchodzi MVP.

Z drugiej strony, ta zasada skali kciuka, może mieć bardzo małą wagę, gdy cechy platformy sprzyjają pewnym relacjom między komponentami, jak w przypadku sieci web, gdzie wydaje się łatwiejsze do wdrożenia MVC, bardziej niż MVP.

Istnieje wiele wersji MVC, ta odpowiedź dotyczy oryginalnego MVC w Smalltalku. Krótko mówiąc, jest to

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. Artykuł nie pojawia się w wynikach wyszukiwania dla zapytań "MVC, MVP i MVVM", ponieważ tytuł artykułu nie zawiera słów "MVC" i "MVP"; ale to jest najlepsze wyjaśnienie, myślę.

(Artykuł pasuje również do tego, co Wujek Bob Martin powiedział w swoim z jego wypowiedzi wynika, że MVC został pierwotnie zaprojektowany dla małych komponentów interfejsu użytkownika, a nie dla architektury systemu.]}

Najprostszą odpowiedzią jest sposób interakcji 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 wymaganą logikę biznesową, a następnie aktualizuje widok. W MVC model aktualizuje Widok bezpośrednio, a nie wraca przez kontroler.

Jest Ten fajny filmik z Wujka Boba, gdzie krótko wyjaśnia MVC & MVP na końcu.

IMO, MVP jest ulepszoną wersją MVC, w której zasadniczo oddzielasz troskę o to, co masz zamiar pokazać (dane) od tego, jak masz zamiar pokazać (widok). Prezenter zawiera logikę biznesową twojego interfejsu użytkownika, domyślnie narzuca jakie dane powinny być prezentowane i daje listę głupich modeli widoku. A kiedy przychodzi czas, aby pokazać dane, po prostu podłącz widok (prawdopodobnie zawiera ten sam IDENTYFIKATOR) do karty i ustaw odpowiednie pola widoku za pomocą tych modeli widoku z minimalną ilością wprowadzanego kodu(po prostu za pomocą ustawień). Jego główną zaletą jest to, że możesz przetestować logikę biznesową interfejsu użytkownika przed wieloma / różnymi widokami, takimi jak wyświetlanie elementów na liście poziomej lub pionowej.

W MVC, mówimy przez interfejsy (granice) do klejenia różnych warstw. Kontroler jest wtyczką do naszej architektury, ale nie ma takiego ograniczenie narzucania tego, co pokazać. W tym sensie MVP jest rodzajem MVC z koncepcją widoków, które można podłączyć do kontrolera za pomocą adapterów.

Mam nadzieję, że to pomoże lepiej.

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

Jak wyjaśniono w niektórych grafikach powyżej, istnieje bezpośrednia relacja/powiązanie między modelem A widokiem w MVC. Akcja jest wykonywana na kontrolerze , który wykona akcję na modelu . To działanie w modelu , spowoduje wywołanie reakcji w widoku . Widok jest zawsze aktualizowany, gdy stan Modelu zmiany.

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

Ponieważ używamy Web frameworków (np:. Laravel ), które nadal używają tych samych konwencji nazewnictwa (model-view-controller ), uważamy, że musi to być MVC, ale to właściwie to coś innego.

Uwaga: Wikipedia stwierdza, że " każde działanie ADR jest jednak reprezentowane przez oddzielne klasy lub zamknięcia.". To jestnie koniecznie prawda. Kilka akcji może być w tym samym kontrolerze, a wzór jest nadal taki sam.

Mvc adr model-widok-kontroler action-domain-responder

W kilku słowach,

• w MVC View posiada część interfejsu użytkownika, która wywołuje kontroler, który z kolei wywołuje model i model z kolei wywołuje zdarzenia z powrotem do widoku.
• w MVP Widok zawiera interfejs użytkownika i wywołuje prezenter dla części implementacji. Prezenter wywołuje Widok bezpośrednio w celu aktualizacji części interfejsu użytkownika. Model, który zawiera logikę biznesową, jest wywoływany przez prezentera i nie ma żadnej interakcji z widokiem. Więc tutaj prezenter wykonuje większość pracy:)

MVP

MVP oznacza Model-View-Presenter. Pojawił się na początku 2007 roku, gdzie Microsoft wprowadził inteligentne aplikacje klienckie windows.

Prezenter pełni rolę nadzorczą w MVP, która wiąże wyświetlanie zdarzeń i logikę biznesową z modeli.

Powiązanie zdarzeń widoku zostanie zaimplementowane w prezenterze z interfejsu widoku.

Widok jest inicjatorem wejść użytkownika, a następnie przekazuje zdarzenia prezenterowi i prezenter obsługuje wiązania zdarzeń i pobiera dane z modeli.

Plusy: Widok ma tylko UI, a nie logikę Wysoki poziom testowalności

Wady: Skomplikowany Bit i więcej pracy przy implementacji wiązań zdarzeń

MVC

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

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

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

Wady: Czasami zbyt dużo pracy dla kontrolerów, jeśli spróbuj renderować wiele widoków w tym samym kontrolerze.