Wat zijn de verschillen tussen Presenter, Presentatie Model, ViewModel en Controller?

Ik heb een redelijk goed idee hoe elk van deze patronen werkt en ken enkele van de kleine verschillen ertussen, maar zijn ze echt zo verschillend van elkaar?

Het lijkt mij dat de Presenter, het Presentatiemodel, het ViewModel en de Controller in wezen hetzelfde concept zijn.

Waarom kon ik niet al deze concepten classificeren als controllers? Ik heb het gevoel dat het het hele idee een stuk eenvoudiger kan maken.

Kan iemand een duidelijke beschrijving geven van hun verschillen?

Ik wil duidelijk maken dat ik begrijp hoe de patronen werken en dat ik de meeste ervan in de een of andere technologie heb geïmplementeerd. Waar ik echt naar op zoek ben, is de ervaring van iemand met een van deze patronen, en waarom ze hun ViewModel bijvoorbeeld niet als een controller zouden beschouwen.

Ik zal hier wat reputatiepunten voor geven, maar ik ben op zoek naar een echt goed antwoord.

Antwoord 1, autoriteit 100%

Naast de reeds genoemde geweldige reads (Fowler & Miller) en om te reageren op uw punt over verschillen tussen controller/presentator/ … vanuit het oogpunt van de ontwikkelaar:

Controller in MVC:

• Controller is het eigenlijke onderdeel dat wordt aangeroepen als gevolg van gebruikersinteractie. (De ontwikkelaar hoeft geen code te schrijven om oproepen aan de controller te delegeren.)

• Controller haalt op de een of andere manier huidige waarden uit de View/context/bag/ wat dan ook, maar je zou niet echt zeggen dat het interageertmet de View.

• Controller beslist uiteindelijk welke weergave aan de gebruiker wordt getoond. Daarin toont Controller ook een expliciete notie van de workflow voor applicatienavigatie.

Present in MVP:

• Presenter heeft methoden die worden aangeroepen door de View, wat het eigenlijke onderdeel is dat controle krijgt bij gebruikersinteractie. (De ontwikkelaar moet een code in de weergave schrijven om de presentator te kunnen bellen.)

• De presentator haalt de huidige waarden op de een of andere manier uit de weergave of ontvangt ze bij oproep uit de weergave. Presentator roept methoden aan in de View om de status in te stellen (vul deze inzegt Josh Smith). Een View-methode die door de Presenter wordt aangeroepen kanhebben verschillende kleine instellingen in zijn hoofdtekst.

• Presentator toont niet expliciet een idee van applicatieworkflow. Het wordt meestal gezien als het teruggeven van de controle aan de aanroepende weergave.

PresentatieModel in PM:

• PresentationModel heeft methoden die worden aangeroepen door de View, het eigenlijke onderdeel dat controle krijgt bij gebruikersinteractie. (De ontwikkelaar moet wat code in de View schrijven om het PresentationModel aan te roepen.)

• PresentationModel heeft een veel spraakzamecommunicatie met View vergeleken met een Presenter. Het bevat ook meer logica om erachter te komen wat de waarde is van alle instellingen die in de View moeten worden toegepast, en om die ook daadwerkelijk in de View in te stellen. (Die View-methoden hebben om de beurt bijna geen logica.)

• PresentationModel laat niet expliciet een notie zien van een applicatieworkflow. Het wordt meestal gezien als het teruggeven van de controle aan de aanroepende weergave.

ViewModel in MVVM:

• ViewModel heeft methoden die worden aangeroepen (& eigenschappen ingesteld) door de View, de eigenlijke component die controle krijgt bij gebruikersinteractie. (De ontwikkelaar moet wat (declaratieve) code in de View schrijven om de ViewModel te kunnen oproepen.)

• ViewModel heeft geen expliciet spraakzame communicatie met View in vergelijking met PresentationModel (d.w.z. het roept View niet veel aan, het framework doet het). Maar het heeft veel eigenschappen die 1 op 1 in kaart brengen met View-instellingen. Het bevat nog steeds dezelfde logica om de waarde van al die instellingen te achterhalen.

• ViewModel toont niet expliciet een notie van applicatieworkflow. Het wordt meestal gezien als het teruggeven van de controle aan de aanroepende weergave.

• Op de een of andere manier kopiëren wat Josh Smith zegt (http://msdn. microsoft.com/en-us/magazine/dd419663.aspx): MVVM-patroon is een speciaal geval van PM dat gebruikmaakt van een framework (zoals WPF/SL) om minder code te schrijven.

Antwoord 2, autoriteit 69%

Martin Fowler heeft een pagina over UI-ontwerppatronen, waarin hij MVC, MVP en andere patronen definieert en vervolgens bespreekt.

http://martinfowler.com/eaaDev/uiArchs.html

Een Controlleris actief bij het besturen van de gebruikersinterface. Het zou bijvoorbeeld alle gebeurtenissen die door de gebruikersinterface worden geactiveerd, afhandelen en op de juiste manier behandelen.

Een Presentatoraan de andere kant is passiever en geeft eenvoudig gegevens weer via de gebruikersinterface, die zijn eigen evenementen enz. afhandelt, of delegeert ze via de presentator aan een dienst of commando.

Een ViewModelis een specifiek voorbeeld van een Presenter, ontworpen voor gebruik met WPF/Silverlight-binding.

Een Presentatiemodelis een model dat rechtstreeks door de weergave kan worden gepresenteerd, dus als uw modellen bijvoorbeeld INotifyPropertyChanged implementeren voor gegevensbinding, zouden het presentatiemodellen zijn.

Antwoord 3, autoriteit 9%

Het verschil tussen beide zit in de hoeveelheid code in de weergave. De keuze tussen hen is in feite een keuze van technologie voor toepassingen zoals WFP, WinForms, ASP MVC(2). Het basisidee om logica en presentatie te scheiden is hetzelfde.

Hieris een heel goed artikel over alle drie.

BEWERKEN:

Nog eenartikel – vergelijking.

Antwoord 4, autoriteit 9%

Naar mijn mening zijn er geen echte conceptuele verschillen tussen MVP, MVVC, MVC en presentatiemodel. Er zijn enkele gedetailleerde verschillen, maar uiteindelijk kan het allemaal worden gezien als een Model View Controller-opstelling. De extra naamgeving dient alleen maar om verwarring te zaaien, en ik denk dat het beter zou zijn om terminologie te gebruiken die een zekere speelruimte laat bij het beschrijven van een controller.

Antwoord 5

Minstens in .Net wordt MVP gebruikt als ontwerppatroon. Dit wordt meestal gebruikt met Windows Forms-toepassingen of klassieke ASP.Net. Bij MVC en MVVC worden deze meestal gebruikt met ASP MVC, dat een vrij andere architectuur gebruikt dan normaal ASP.Net.

Antwoord 6

Een belangrijk onderscheid tussen MVP en MVVM is dat VM met veel weergaven kan worden gebruikt, MVP is meestal 1-1 tussen Presenter en View met een contractinterface die zijn methoden afdwingt.
Android heeft veel gedaan om MVVM op te nemen in de ViewModel-component die bovenop een behouden fragment is gebouwd. Het is het patroon bij uitstek voor Architectuur en zeer geschikt voor elke app.