Vraag Wat zijn MVP en MVC en wat is het verschil?


Wanneer je verder kijkt dan de RAD (drag-drop en configure) manier om gebruikersinterfaces te bouwen die door veel tools worden aangemoedigd, komen waarschijnlijk drie ontwerppatronen tegen Model-View-Controller, Model-View-Presenter en Model-View-ViewModel. Mijn vraag bestaat uit drie delen:

  1. Op welke problemen richten deze patronen zich?
  2. Hoe zijn ze vergelijkbaar?
  3. Hoe zijn zij verschillend?

1834
2017-08-05 10:06


oorsprong


antwoorden:


Model-View-Presenter

In MVP, de presentator bevat de bedrijfslogica van de gebruikersinterface voor de weergave. Alle aanroepen van de View delegate rechtstreeks naar Presenter. De presentator is ook rechtstreeks ontkoppeld van de weergave en praat ermee via een interface. Dit is bedoeld om de View in een unit-test te bespotten. Een gebruikelijk kenmerk van MVP is dat er veel tweerichtingsverkeer moet zijn. Wanneer iemand bijvoorbeeld op de knop "Opslaan" klikt, delegeert de gebeurtenishandler naar de "OnSave" -methode van de presentator. Nadat het opslaan is voltooid, roept de presentator de weergave vervolgens via de interface terug zodat de weergave kan weergeven dat het opslaan is voltooid.

MVP is meestal een heel natuurlijk patroon voor het bereiken van gescheiden presentatie in webformulieren. De reden is dat de weergave altijd eerst wordt gemaakt door de ASP.NET-runtime. Jij kan lees meer over beide varianten.

Twee primaire variaties

Passieve weergave: De weergave is zo stom mogelijk en bevat bijna nul logica. De presentator is een tussenpersoon die praat met de weergave en het model. De weergave en het model zijn volledig afgeschermd van elkaar. Het model kan gebeurtenissen verhogen, maar de presentator schrijft zich in voor het bijwerken van de weergave. In de passieve weergave is er geen directe gegevensbinding, in plaats daarvan worden in de weergave eigenschappen van de setter weergegeven die de presentator gebruikt om de gegevens in te stellen. Alle status wordt beheerd in de Presenter en niet in de weergave.

  • Pro: maximaal testbaarheidsoppervlak; schone scheiding van de weergave en het model
  • Con: meer werk (bijvoorbeeld alle eigenschappen van de setter) terwijl u alle gegevens zelf aan het binden bent.

Toezichthoudende controller: De presentator verwerkt gebruikersbewegingen. De weergave bindt rechtstreeks aan het model via databinding. In dit geval is het de taak van de presentator om het model door te geven aan de weergave, zodat deze eraan kan worden gekoppeld. De presentator bevat ook logica voor gebaren zoals het indrukken van een knop, navigatie, enz.

  • Pro: door gebruik te maken van databinding wordt de hoeveelheid code verminderd.
  • Con: er is minder testbaar oppervlak (vanwege databinding) en er is minder inkapseling in de weergave omdat het rechtstreeks met het model praat.

Model-View-Controller

In de MVC, de controller is verantwoordelijk voor het bepalen welke weergave moet worden weergegeven als reactie op een actie, inclusief wanneer de toepassing wordt geladen. Dit verschilt van MVP waar acties door de weergave naar de presentator worden geleid. In MVC correleert elke actie in de weergave met een oproep aan een controller samen met een actie. In het web omvat elke actie een aanroep naar een URL aan de andere kant waarvan er een controller is die antwoordt. Zodra die controller de verwerking heeft voltooid, retourneert deze de juiste weergave. De volgorde gaat op die manier door gedurende de hele levensduur van de applicatie:

Actie in de weergave
        -> Oproep naar controller
        -> Controller Logic
        -> Controller retourneert de weergave.

Een ander groot verschil met MVC is dat de View niet rechtstreeks aan het Model bindt. Het uitzicht wordt gewoon weergegeven en is volledig staatloos. In implementaties van MVC heeft de View meestal geen logica in de code erachter. Dit is in tegenstelling tot MVP, waar het absoluut noodzakelijk is, want als de View niet delegeert naar de Presenter, wordt deze nooit gebeld.

Presentatiemodel

Een ander patroon om naar te kijken is het Presentatiemodel patroon. In dit patroon is er geen presentator. In plaats daarvan bindt de View rechtstreeks aan een presentatiemodel. Het presentatiemodel is een model dat speciaal is ontworpen voor de weergave. Dit betekent dat dit model eigenschappen kan blootleggen die men nooit op een domeinmodel zou plaatsen, omdat het een schending van de scheiding van zorgpunten zou zijn. In dit geval bindt het presentatiemodel zich aan het domeinmodel en kan het zich abonneren op gebeurtenissen die uit dat model komen. The View abonneert zich vervolgens op gebeurtenissen die afkomstig zijn van het presentatiemodel en werkt zichzelf dienovereenkomstig bij. Het presentatiemodel kan opdrachten blootleggen die de weergave gebruikt voor het aanroepen van acties. Het voordeel van deze aanpak is dat je de achterliggende code in essentie kunt verwijderen, omdat de PM het gedrag van het beeld volledig inkapselt. Dit patroon is een zeer sterke kandidaat voor gebruik in WPF-toepassingen en wordt ook wel genoemd Model-View-ViewModel.

Er is een MSDN-artikel over het presentatiemodel en een sectie in de Samengestelde applicatiegids voor WPF (voormalig Prisma) over Gescheiden presentatiepatronen


1796
2017-08-05 10:21



Ik heb hier een tijdje over geblogd en geciteerd De uitstekende post van Todd Snyder over het verschil tussen de twee:

Hier zijn de belangrijkste verschillen tussen   de patronen:

MVP-patroon

  • Beeld is losser gekoppeld aan het model. De presentator is   verantwoordelijk voor het binden van het model aan   het uitzicht.
  • Makkelijker om unit-tests uit te voeren omdat interactie met het beeld erdoorheen is   een interface
  • Meestal wordt de weergave van de presentator één voor één afgebeeld. Complexe visies kunnen hebben   multi-presenters.

MVC-patroon

  • Controller is gebaseerd op gedrag en kan worden gedeeld   keer bekeken
  • Kan verantwoordelijk zijn voor het bepalen welke weergave moet worden weergegeven

Het is de beste verklaring op het web die ik kon vinden.


384
2017-07-06 22:18



Dit is een oversimplificatie van de vele varianten van deze ontwerppatronen, maar dit is hoe ik graag nadenk over de verschillen tussen de twee.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Dit zijn illustraties die de communicatiestroom weergeven

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP is niet noodzakelijkerwijs een scenario waarin de View de leiding heeft (zie Taligent's MVP bijvoorbeeld).
Ik vind het jammer dat mensen dit nog steeds als een patroon prediken (View in charge) in tegenstelling tot een anti-patroon omdat het in tegenspraak is met "Het is maar een weergave" (Pragmatic Programmer). "Het is maar een weergave" stelt dat de laatste weergave voor de gebruiker een bijkomstigheid is van de toepassing. Microsoft's MVP-patroon maakt het hergebruik van Views veel moeilijker en gunstig verontschuldigt de ontwerper van Microsoft van het aanmoedigen van slechte praktijken.

Om eerlijk te zijn, denk ik dat de onderliggende zorgen van MVC gelden voor elke MVP-implementatie en dat de verschillen bijna volledig semantisch zijn. Zolang u een scheiding van punten van zorg volgt tussen de weergave (die de gegevens weergeeft), de controller (die de gebruikersinteractie initialiseert en beheert) en het model (de onderliggende gegevens en / of services)), bereikt u de voordelen van MVC . Als u de voordelen opdoet, wat maakt het dan echt uit of uw patroon MVC, MVP of Supervising Controller is? De enige echt patroon blijft als MVC, de rest zijn gewoon verschillende smaken.

Overwegen deze zeer opwindend artikel dat een uitgebreid overzicht geeft van een aantal van deze verschillende implementaties. Je zou kunnen opmerken dat ze allemaal in principe hetzelfde doen, maar iets anders.

Ik denk persoonlijk dat MVP pas onlangs opnieuw is geïntroduceerd als een pakkende term om argumenten tussen semantische daders te verminderen die beweren dat iets echt MVC is of niet, of om de Rapid Application Development-tools van Microsoft te rechtvaardigen. Geen van deze redenen in mijn boeken rechtvaardigt zijn bestaan ​​als een afzonderlijk ontwerppatroon.


148
2017-08-06 22:51



MVP: de mening heeft de leiding.

Het beeld creëert in de meeste gevallen de presentator. De presentator communiceert met het model en manipuleert de weergave via een interface. De weergave zal soms interactie hebben met de presentator, meestal via een bepaalde interface. Dit komt neer op implementatie; wilt u dat de weergave methoden op de presentator aanroept of wilt u dat de weergave gebeurtenissen bevat waarnaar de presentator luistert? Het komt hierop neer: het beeld kent de presentator. Het aanzicht delegeert naar de presentator.

MVC: de controller heeft de leiding.

De controller wordt gemaakt of geopend op basis van een gebeurtenis / verzoek. De controller maakt vervolgens de juiste weergave en communiceert met het model om de weergave verder te configureren. Het komt neer op: de controller maakt en beheert de weergave; het beeld is slaaf van de controller. Het beeld kent de controller niet.


90
2017-12-20 02:10



enter image description here

MVC (Model View Controller)

De invoer wordt eerst op de controller gericht, niet op de weergave. Die invoer kan afkomstig zijn van een gebruiker die op een pagina reageert, maar het kan ook zijn door simpelweg een specifieke URL in een browser in te voeren. In beide gevallen is het een controller die is gekoppeld om een ​​aantal functies te starten. Er is een veel-op-één-relatie tussen de controller en de weergave. Dat komt omdat een enkele controller verschillende weergaven kan selecteren die moeten worden weergegeven op basis van de bewerking die wordt uitgevoerd. Let op de eenrichtingspijl van Controller naar View. Dit komt omdat de View geen kennis van of verwijzing naar de controller heeft. De controller geeft het model wel terug, dus er is kennis tussen de weergave en het verwachte model dat erin wordt doorgegeven, maar niet de controller die het model gebruikt.

MVP (Model View Presenter)

De invoer begint met de weergave, niet met de presentator. Er is een één-op-één-toewijzing tussen de weergave en de bijbehorende presentator. De weergave bevat een verwijzing naar de presentator. De presentator reageert ook op gebeurtenissen die worden geactiveerd vanuit de weergave, dus op de hoogte van de weergave waarmee deze is geassocieerd. De Presentator werkt de weergave bij op basis van de gevraagde acties die het uitvoert op het model, maar de weergave is niet Modelbewust.

Voor meer Referentie


62
2017-08-05 10:22



  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Beide presentaties. Ze scheiden de afhankelijkheden tussen een model (denk aan domeinobjecten), uw scherm / webpagina (de weergave) en hoe uw gebruikersinterface hoort te gedragen (presentator / controller)
    2. Ze zijn redelijk vergelijkbaar in concept, mensen initialiseren de Presenter / Controller anders, afhankelijk van de smaak.
    3. Een geweldig artikel over de verschillen is hier. Het meest opvallende is dat het MVC-patroon het model heeft om de weergave bij te werken.

31
2017-08-08 05:55



Het is ook de moeite waard om te onthouden dat er ook verschillende soorten MVP's zijn. Fowler heeft het patroon in tweeën gebroken - passieve controle- en controleregelaar.

Wanneer u Passieve weergave gebruikt, implementeert uw View meestal een fijnmazige interface met eigenschappen die min of meer rechtstreeks zijn gekoppeld aan de onderliggende UI-widget. U kunt bijvoorbeeld een ICustomerView hebben met eigenschappen zoals Naam en Adres.

Uw implementatie ziet er ongeveer zo uit:

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

Uw Presenter-klasse spreekt met het model en "kaart" het in de weergave. Deze benadering wordt de "Passieve weergave" genoemd. Het voordeel is dat de weergave eenvoudig kan worden getest en dat het gemakkelijker is om te schakelen tussen UI-platforms (web, Windows / XAML, enz.). Het nadeel is dat je niet kunt profiteren van dingen als databinding (dat is werkelijk krachtig in raamwerken zoals WPF en Silverlight).

De tweede smaak van MVP is de controlerende controller. In dat geval heeft uw weergave mogelijk een eigenschap met de naam Klant, die vervolgens opnieuw wordt gegroepeerd naar de UI-widgets. U hoeft niet na te denken over synchronisatie en micro-beheer van de weergave, en de superviserende controller kan ingrijpen en helpen wanneer dat nodig is, bijvoorbeeld met behulp van compatibele interactielogica.

De derde "smaak" van MVP (of iemand zou het misschien een afzonderlijk patroon noemen) is het presentatiemodel (of wordt soms Model-View-ViewModel genoemd). In vergelijking met de MVP "voeg je" de M en de P samen in één klasse. U hebt uw klantobject waarvoor op uw UI-widgets gegevens zijn gebonden, maar u hebt ook aanvullende UI-specifieke velden zoals "IsButtonEnabled" of "IsReadOnly", enz.

Ik denk dat de beste bron die ik tot de UI-architectuur heb gevonden, de serie blogposts is die Jeremy Miller heeft gedaan bij De inhoudsopgave van de Build Your Own CAB-serie. Hij behandelde alle smaken van MVP en toonde C # -code om ze te implementeren.

Ik heb ook geblogd over het patroon Model-View-ViewModel in de context van Silverlight over at YouCard Re-visited: Implementeren van het ViewModel-patroon.


31
2018-04-06 13:51



Er zijn veel antwoorden op de vraag, maar ik vond dat er behoefte is aan een heel eenvoudig antwoord waarin de twee duidelijk worden vergeleken. Dit is de discussie die ik heb gemaakt toen een gebruiker in een MVP- en MVC-app naar een filmnaam zoekt:

Gebruiker: klik klik ...

Uitzicht: Wie is dat? [MVP|MVC]

Gebruiker: ik klikte gewoon op de zoekknop ...

Uitzicht: Oké, wacht even ... [MVP|MVC]

( Uitzicht het aanroepen van de Presentator|controleur ...) [MVP|MVC]

Uitzicht: Hallo Presentator|controleur, een gebruiker heeft zojuist op de zoekknop geklikt, wat moet ik doen? [MVP|MVC]

Presentator|controleur: Hallo Uitzicht, is er een zoekterm op die pagina? [MVP|MVC]

Uitzicht: Ja, ... hier is het ... "piano" [MVP|MVC]

Presentator: Bedankt Uitzicht, ... ondertussen kijk ik de zoekterm op de Model, laat hem / haar een voortgangsbalk zien [MVP|MVC]

( Presentator|controleur roept het Model ...) [MVP|MVC]

Presentator|controleur: Hallo Model, Heb je een match voor deze zoekopdracht ?: "piano" [MVP|MVC]

Model: Hallo Presentator|controleur, laat me kijken ... [MVP|MVC]

( Model is een query aan de filmdatabase aan het maken ...) [MVP|MVC]

( Na een tijdje ... )

-------------- Hier komen MVP en MVC uit elkaar te lopen ---------------

Model: Ik heb een lijst voor je gevonden, Presentator, hier is het in JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [MVP]

Model: Er is enig resultaat beschikbaar, controleur. Ik heb een veldvariabele gemaakt in mijn instantie en deze gevuld met het resultaat. De naam is "searchResultsList" [MVC]

(Presentator|controleur bedankt Model en gaat terug naar de Uitzicht) [MVP|MVC]

Presentator: Bedankt voor het wachten Uitzicht, Ik vond een lijst met overeenkomende resultaten voor je en arrangeerde ze in een presentabel formaat: ["Piano Teacher 2001", "Piano 1993"]. Toon het alsjeblieft aan de gebruiker in een verticale lijst. Verberg ook de voortgangsbalk nu [MVP]

controleur: Bedankt voor het wachten Uitzicht, Ik heb gevraagd Model over uw zoekopdracht. Er staat dat het een lijst met overeenkomende resultaten heeft gevonden en deze heeft opgeslagen in een variabele met de naam "searchResultsList" in zijn instantie. Je kunt het vanaf daar krijgen. Verberg ook de voortgangsbalk nu [MVC]

Uitzicht: Veel dank Presentator [MVP]

Uitzicht: Bedankt "Controller" [MVC] (Nu de Uitzicht stelt zichzelf de vraag: hoe moet ik de resultaten presenteren die ik krijg van de Model voor de gebruiker? Moet het productiejaar van de film voor het eerst of het laatst plaatsvinden ...? Moet het in een verticale of horizontale lijst staan? ...)

Als je geïnteresseerd bent, heb ik een reeks artikelen geschreven over app-architecturale patronen (MVC, MVP, MVVP, clean architecture, ...) vergezeld van een Github-repo hier. Hoewel het voorbeeld voor android is geschreven, kunnen de onderliggende principes op elk medium worden toegepast.


17
2017-08-05 10:20