Als we verder kijken dan de RAD(slepen en configureren) manier om gebruikersinterfaces te bouwen die veel tools moedigen u aan om drie ontwerppatronen tegen te komen, genaamd Model-View-Controller, Model-View -Presentatoren Model-View-ViewModel. Mijn vraag bestaat uit drie delen:
- Welke problemen lossen deze patronen op?
- Hoe lijken ze op elkaar?
- Hoe verschillen ze?
Antwoord 1, autoriteit 100%
Model-View-Presenter
In MVPbevat de Presenter de bedrijfslogica van de gebruikersinterface voor de weergave. Alle aanroepen van de View-gemachtigde rechtstreeks naar de presentator. De Presenter is ook direct losgekoppeld van de View en praat ermee via een interface. Dit is om het spotten van de weergave in een unit-test mogelijk te maken. Een gemeenschappelijk kenmerk van MVP is dat er veel tweerichtingsverkeer moet zijn. Als iemand bijvoorbeeld op de knop ‘Opslaan’ klikt, delegeert de gebeurtenishandler naar de ‘OnSave’-methode van de presentator. Zodra het opslaan is voltooid, roept de presentator de View terug via de interface, zodat de View kan weergeven dat het opslaan is voltooid.
MVP is meestal een heel natuurlijk patroon voor het bereiken van gescheiden presentatie in WebForms. De reden is dat de View altijd eerst wordt gemaakt door de ASP.NET-runtime. U kunt vinden lees meer over beide varianten.
Twee primaire varianten
Passieve weergave:de weergave is zo dom mogelijk en bevat bijna geen logica. Een presentator is een tussenpersoon die met de View en het Model praat. De View en Model zijn volledig van elkaar afgeschermd. Het model kan gebeurtenissen oproepen, maar de presentator onderschrijft ze voor het bijwerken van de weergave. In Passive View is er geen directe gegevensbinding, in plaats daarvan stelt de View setter-eigenschappen bloot die de Presenter gebruikt om de gegevens in te stellen. Alle status wordt beheerd in de Presenter en niet in de weergave.
- Pro: maximaal testbaar oppervlak; schone scheiding van het aanzicht en het model
- Con: meer werk (bijvoorbeeld alle setter-eigenschappen) omdat je alle gegevensbinding zelf doet.
Toezichthouder:de presentator handelt gebruikersgebaren af. De weergave wordt rechtstreeks aan het model gekoppeld via gegevensbinding. In dit geval is het de taak van de presentator om het model door te geven aan de weergave zodat het eraan kan binden. De Presenter 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.
- Nadeel: er is een minder testbaar oppervlak (vanwege gegevensbinding) en er is minder inkapseling in de weergave omdat deze rechtstreeks met het model praat.
Model-View-Controller
In de MVC is de controller verantwoordelijk voor het bepalen van de weergave die wordt weergegeven in reactie op elke actie, inclusief wanneer de aanvraagbelastingen. Dit verschilt van MVP waar actiesroute door het uitzicht op de presentator zijn. In MVC correleert elke actie in de weergave met een oproep aan een controller samen met een actie. Op internet betreft elke actie een oproep aan een URL aan de andere kant waarvan er een controller is die reageert. Zodra die controller zijn verwerking heeft voltooid, zal deze de juiste weergave retourneren. De sequentie gaat op die manier door in het hele leven van de toepassing:
Actie in de weergave
- & GT; Bel naar controller
- & GT; Controller logica
- & GT; Controller keert terug.
Een ander groot verschil over MVC is dat het standpunt niet rechtstreeks aan het model bindt. Het uitzicht maakt simpelweg en is volledig stateloos. In implementaties van MVC heeft de weergave meestal geen logica in de code achter. Dit is in strijd met MVP waar het absoluut noodzakelijk is, omdat, als de weergave niet deelneemt aan de presentator, het nooit zal worden genoemd.
Presentatiemodel
Een ander patroon om naar te kijken is het Presentatiemodelpatroon. In dit patroon is er geen presentator. In plaats daarvan wordt de weergave rechtstreeks gekoppeld aan een presentatiemodel. Het presentatiemodel is een model dat speciaal voor de weergave is gemaakt. Dit betekent dat dit model eigenschappen kan blootleggen die men nooit op een domeinmodel zou plaatsen, omdat het een schending van de scheiding van zorgen zou zijn. In dit geval bindt het presentatiemodel aan het domeinmodel en kan het zich abonneren op gebeurtenissen die uit dat model komen. De View onderschrijft dan gebeurtenissen die uit het Presentatiemodel komen en werkt zichzelf dienovereenkomstig bij. Het presentatiemodel kan opdrachten weergeven die de weergave gebruikt voor het aanroepen van acties. Het voordeel van deze aanpak is dat je de achterliggende code in wezen helemaal kunt verwijderen, omdat de PM al het gedrag voor de weergave volledig inkapselt. Dit patroon is een zeer sterke kandidaat voor gebruik in WPF-toepassingen en wordt ook wel Model-View genoemd -ViewModel.
Er is een MSDN-artikel over het presentatiemodelen een sectie in de Samengestelde toepassingsrichtlijnen voor WPF(voorheen Prism) over Gescheiden presentatiepatronen
Antwoord 2, autoriteit 24%
Dit is een te grote vereenvoudiging van de vele varianten van deze ontwerppatronen, maar zo denk ik graag na over de verschillen tussen de twee.
MVC
MVP
Antwoord 3, autoriteit 21%
Ik heb hier een tijdje geleden over geblogd en geciteerd op Todd Snyder’s uitstekende bericht over het verschil tussen de twee:
Dit zijn de belangrijkste verschillen tussen:
de patronen:MVP-patroon
- View is losser gekoppeld aan het model. De presentator is
verantwoordelijk voor het binden van het model aan
het uitzicht.- Eenvoudig te testen omdat de interactie met de weergave is voltooid
een interface- Meestal één-op-één weergave naar presentator toewijzen. Complexe weergaven kunnen hebben
meerdere presentatoren.MVC-patroon
- Controller is gebaseerd op gedrag en kan met anderen worden gedeeld
weergaven- Kan verantwoordelijk zijn voor het bepalen welke weergave moet worden weergegeven
Het is de beste uitleg op internet die ik kon vinden.
Antwoord 4, autoriteit 13%
Hier zijn illustraties die de communicatiestroom weergeven
Antwoord 5, autoriteit 9%
MVP is nietnoodzakelijkerwijs een scenario waarbij de View de leiding heeft (zie bijvoorbeeld Taligent’s MVP).
Ik vind het jammer dat mensen dit nog steeds prediken als een patroon (View in charge) in tegenstelling tot een anti-patroon omdat het in tegenspraak is met “Het is maar een mening” (Pragmatic Programmer). “Het is maar een weergave” stelt dat de uiteindelijke weergave die aan de gebruiker wordt getoond, een secundaire zorg is van de toepassing. Het MVP-patroon van Microsoft maakt hergebruik van Views veel moeilijker en het is handigeen excuus voor de ontwerper van Microsoft om slechte praktijken aan te moedigen.
Om heel 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 de scheiding van zorgen volgt tussen de weergave (die de gegevens weergeeft), de controller (die de gebruikersinteractie initialiseert en regelt) en het model (de onderliggende gegevens en/of services)), dan profiteert u van de voordelen van MVC . Als u de voordelen behaalt, wat maakt het dan uit of uw patroon MVC, MVP of Supervising Controller is? Het enige echtepatroon blijft als MVC, de rest zijn gewoon verschillende smaken ervan.
Bekijk ditzeer opwindende artikel dat een uitgebreide lijst geeft van een aantal van deze verschillende implementaties.
Je merkt misschien dat ze allemaal hetzelfde doen, maar iets anders.
Persoonlijk denk ik dat MVP pas onlangs opnieuw is geïntroduceerd als een pakkende term om ofwel ruzies tussen semantische dwepers die beweren of iets echt MVC is of niet, te verminderen of om de Rapid Application Development-tools van Microsoft te rechtvaardigen. Geen van deze redenen in mijn boeken rechtvaardigt het bestaan ervan als een afzonderlijk ontwerppatroon.
Antwoord 6, autoriteit 6%
MVP: het uitzicht is de baas.
De weergave maakt in de meeste gevallen de presentator aan. De presentator zal interactie hebben met het model en de weergave manipuleren via een interface. De weergave zal soms communiceren met de presentator, meestal via een interface. Dit komt neer op implementatie; wilt u dat de weergave methoden aanroept op de presentator of wilt u dat de weergave gebeurtenissen bevat waarnaar de presentator luistert? Het komt hier op neer: het uitzicht weet van de presentator. De weergave wordt gedelegeerd aan 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 werkt samen met het model om de weergave verder te configureren. Het komt erop neer: de controller maakt en beheert de view; het uitzicht is slaaf van de controller. De weergave is niet op de hoogte van de controller.
Antwoord 7, autoriteit 4%
MVC (Model View Controller)
De invoer is eerst naar de controller gericht, niet naar het zicht. Die invoer kan afkomstig zijn van een gebruiker die interactie heeft met een pagina, maar het kan ook zijn door simpelweg een specifieke url in een browser in te voeren. In beide gevallen is het een controller waarmee een interface wordt gestart om wat functionaliteit te starten.
Er is een veel-op-een relatie tussen de Verwerkingsverantwoordelijke en de View. 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 heeft van of verwijst naar de controller.
De Controller geeft het Model wel terug, dus er is kennis tussen de View en het verwachte Model dat erin wordt doorgegeven, maar niet de Controller die het aanbiedt.
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 vanuit de weergave worden geactiveerd, dus hij is zich bewust van de weergave waarmee deze is geassocieerd.
De presentator werkt de weergave bij op basis van de gevraagde acties die hij uitvoert op het model, maar de weergave is niet op de hoogte van het model.
Voor meer Referentie
Antwoord 8, autoriteit 2%
Model-View-Controller
MVCis een patroon voor de architectuur van een softwaretoepassing. Het verdeelt de applicatielogica in drie afzonderlijke delen, wat de modulariteit en het gemak van samenwerking en hergebruik bevordert. Het maakt applicaties ook flexibeler en gastvrijer voor iteraties. Het verdeelt een applicatie in de volgende componenten:
- Modellenvoor het verwerken van gegevens en bedrijfslogica
- Controllersvoor het afhandelen van de gebruikersinterface en applicatie
- Weergavenvoor het verwerken van grafische gebruikersinterface-objecten en presentatie
Om dit wat duidelijker te maken, stellen we ons een eenvoudige boodschappenlijst-app voor. Het enige wat we willen is een lijst met de naam, hoeveelheid en prijs van elk item dat we deze week moeten kopen. Hieronder beschrijven we hoe we een deel van deze functionaliteit kunnen implementeren met MVC.
Model-View-Presenter
- Het modelzijn de gegevens die worden weergegeven in de weergave (gebruikersinterface).
- De weergaveis een interface die gegevens (het model) weergeeft en gebruikersopdrachten (gebeurtenissen) doorstuurt naar de presentator om op die gegevens te reageren. De weergave heeft meestal een verwijzing naar de presentator.
- De Presenteris de “tussenpersoon” (gespeeld door de controller in MVC) en heeft verwijzingen naar zowel weergave als model. Houd er rekening mee dat het woord ‘Model’misleidend is. Het zou eerder bedrijfslogica moeten zijn die een Model ophaalt of manipuleert. Bijvoorbeeld: als u een database hebt waarin de gebruiker is opgeslagen in een databasetabel en uw weergave een lijst met gebruikers wil weergeven, dan heeft de presentator een verwijzing naar de bedrijfslogica van uw database (zoals een DAO) van waaruit de presentator een lijst zal opvragen van gebruikers.
Als je een voorbeeld wilt zien met een eenvoudige implementatie, kijk dan op
ditGitHub-bericht
Een concrete workflow voor het opvragen en weergeven van een lijst met gebruikers uit een database zou als volgt kunnen werken:
Wat is het verschiltussen MVCen MVPpatronen?
MVC-patroon
-
Controller is gebaseerd op gedrag en kan worden gedeeld door verschillende weergaven
-
Kan verantwoordelijk zijn voor het bepalen welke weergave moet worden weergegeven (Front Controller Pattern)
MVP-patroon
-
View is losser gekoppeld aan het model. De presentator is verantwoordelijk voor het binden van het model aan de weergave.
-
Eenvoudiger te testen omdat de interactie met de weergave via een interface verloopt
-
Meestal één-op-één weergave naar presentator toewijzen. Complexe weergaven kunnen meerdere presentatoren hebben.
Antwoord 9, autoriteit 2%
- MVP = Model-View-Presenter
-
MVC = Model-View-Controller
- Beide presentatiepatronen. Ze scheiden de afhankelijkheden tussen een model (denk aan domeinobjecten), uw scherm/webpagina (de weergave) en hoe uw gebruikersinterface zich hoort te gedragen (presentator/controller)
- Ze lijken qua concept redelijk op elkaar, mensen initialiseren de presentator/controller anders, afhankelijk van de smaak.
- Een geweldig artikel over de verschillen is hier. Het meest opvallende is dat het MVC-patroon het model de weergave laat bijwerken.
Antwoord 10, autoriteit 2%
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: Passive View en Supervising Controller.
Als u passieve weergave gebruikt, implementeert uw weergave doorgaans een fijnmazige interface met eigenschappen die min of meer rechtstreeks worden toegewezen aan de onderliggende UI-widget. U kunt bijvoorbeeld een ICustomerView hebben met eigenschappen zoals Naam en Adres.
Uw implementatie kan er ongeveer zo uitzien:
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Je Presenter-klas zal met het model praten en het aan de weergave ‘toewijzen’. Deze benadering wordt de “Passive View” genoemd. Het voordeel is dat de weergave eenvoudig te testen is en dat het gemakkelijker is om tussen UI-platforms (web, Windows/XAML, enz.) te wisselen. Het nadeel is dat je geen gebruik kunt maken van zaken als databinding (wat echtkrachtig is in frameworks zoals WPFen Silverlight).
De tweede variant van MVP is de Supervising Controller. In dat geval heeft uw View mogelijk een eigenschap met de naam Klant, die dan weer datagebonden is aan de UI-widgets. U hoeft niet na te denken over het synchroniseren en micro-managen van de weergave, en de Supervising Controller kan ingrijpen en helpen wanneer dat nodig is, bijvoorbeeld met complete interactielogica.
De derde “smaak” van MVP (of iemand zou het misschien een apart patroon noemen) is het presentatiemodel (of soms aangeduid als Model-View-ViewModel). Vergeleken met de MVP “voeg” je de M en de P samen in één klasse. U hebt uw klantobject waaraan uw UI-widgets gegevens gebonden zijn, maar u heeft ook extra UI-specifieke velden zoals “IsButtonEnabled” of “IsReadOnly”, enz.
Ik denk dat de beste bron die ik heb gevonden voor UI-architectuur de reeks blogposts is van Jeremy Miller op De inhoudsopgave van de Build Your Own CAB Series. Hij behandelde alle smaken van MVP en toonde C#-code om ze te implementeren.
Ik heb ook geblogd over het Model-View-ViewModel-patroon in de context van Silverlight op YouCard opnieuw bezocht: implementatie van het ViewModel-patroon.
Antwoord 11
Ze pakken elk verschillende problemen aan en kunnen zelfs worden gecombineerd om zoiets als hieronder te krijgen
Er is ook een volledige vergelijking van MVC, MVP en MVVM hier
Antwoord 12
Beide frameworks zijn bedoeld om zorgen te scheiden – bijvoorbeeld interactie met een gegevensbron (model), applicatielogica (of deze gegevens omzetten in bruikbare informatie) (Controller/Presenter) en weergavecode (View). In sommige gevallen kan het model ook worden gebruikt om van een gegevensbron een abstractie op een hoger niveau te maken. Een goed voorbeeld hiervan is het MVC Storefront-project.
Er is een discussie gaande hierover de verschillen tussen MVC en MVP.
Het onderscheid dat wordt gemaakt is dat in een MVC-toepassing traditioneel de view en de controller wel met het model communiceren, maar niet met elkaar.
MVP-ontwerpen zorgen ervoor dat de presentator toegang heeft tot het model en interactie heeft met de weergave.
Dat gezegd hebbende, ASP.NET MVC is volgens deze definities een MVP-framework omdat de controller toegang heeft tot het model om de weergave te vullen die bedoeld is om geen logica te hebben (geeft alleen de variabelen weer die door de controller worden geleverd).
Om misschien een idee te krijgen van het onderscheid tussen ASP.NET MVC en MVP, bekijk deze MIX-presentatie door Scott Hanselman.
Antwoord 13
Beide zijn patronen die proberen om presentatie- en bedrijfslogica te scheiden, waarbij bedrijfslogica wordt losgekoppeld van UI-aspecten
Architectonisch gezien is MVP een op Page Controller gebaseerde benadering, terwijl MVC een op Front Controller gebaseerde benadering is.
Dat betekent dat de levenscyclus van een MVP-standaardwebformulierpagina alleen wordt verbeterd door de bedrijfslogica uit de achterliggende code te halen. Met andere woorden, de pagina is het enige HTTP-verzoek. Met andere woorden, MVP IMHO is een evolutionair type verbetering in webvorm.
MVC daarentegen verandert het spel volledig omdat het verzoek wordt onderschept door de controllerklasse voordat de pagina wordt geladen, de bedrijfslogica daar wordt uitgevoerd en vervolgens bij het eindresultaat van de verwerking van de gegevens die zojuist naar de pagina zijn gedumpt (“view”)
In die zin lijkt MVC (althans voor mij) veel op de Supervising Controller-smaak van MVP, verbeterd met routing-engine
Beide schakelen TDD in en hebben voor- en nadelen.
Beslissing over hoe een van hen te kiezen IMHO zou gebaseerd moeten zijn op hoeveel tijd men heeft geïnvesteerd in ASP NET webformulier-type webontwikkeling.
Als iemand zichzelf goed zou vinden in webformulieren, zou ik MVP aanraden.
Als iemand zich niet zo op zijn gemak zou voelen in zaken als de levenscyclus van een pagina, enz., zou MVC een manier kunnen zijn om hier naartoe te gaan.
Hier is nog een link naar een blogpost met wat meer details over dit onderwerp
Antwoord 14
Ik heb zowel MVP als MVC gebruikt en hoewel wij als ontwikkelaars de neiging hebben om ons te concentreren op de technische verschillen van beide patronen, heeft het punt voor MVP in IMHO veel meer te maken met het gemak van adoptie dan met iets anders.
Als ik in een team werk dat al een goede achtergrond heeft in het ontwikkelen van webformulieren, is het veel gemakkelijker om MVP te introduceren dan MVC. Ik zou zeggen dat MVP in dit scenario een snelle overwinning is.
Mijn ervaring leert me dat het relatief eenvoudig is om een team van webformulieren naar MVP en vervolgens van MVP naar MVC te verplaatsen; overstappen van webformulieren naar MVC is moeilijker.
Ik laat hier een link achter naar een reeks artikelen die een vriend van mij heeft gepubliceerd over MVP en MVC.
http://www.qsoft.be/ post/Building-the-MVP-StoreFront-Gutthrie-style.aspx
Antwoord 15
In MVP haalt de weergave gegevens van de presentator die gegevens uit het model trekt en voorbereidt/normaliseert, terwijl in MVC de controller gegevens uit het model haalt en instelt, door de weergave in te drukken.
In MVP kun je een enkele weergave hebben die werkt met meerdere soorten presentatoren en een enkele presentator die met verschillende meerdere weergaven werkt.
MVP gebruikt meestal een soort bindingsframework, zoals Microsoft WPF bindingsframework of verschillende bindingsframeworks voor HTML5 en Java.
In die kaders weet de UI/HTML5/XAML welke eigenschap van de presentator elk UI-element weergeeft, dus wanneer u een weergave aan een presentator koppelt, zoekt de weergave naar de eigenschappen en weet hoe gegevens uit en hoe u ze kunt instellen wanneer een waarde door de gebruiker in de gebruikersinterface wordt gewijzigd.
Dus, als het model bijvoorbeeld een auto is, dan is de presentator een soort van een autopresentator, legt de auto-eigenschappen (jaar, maker, zitplaatsen, enz.) bloot aan het uitzicht. De weergave weet dat het tekstveld ‘Car Maker’ wordt genoemd, moet de eigenschap Presenter Maker weergeven.
U kunt dan binden aan de weergave Veel verschillende soorten presentator, alles moet een maker-eigendom hebben – het kan van een vlak, trein of wat ooit het uitzicht maakt. De weergave tekent gegevens uit de presentator – ongeacht welke – zolang het een overeengekomen interface implementeert.
Dit bindingskader, als u het verlaat, is het eigenlijk de controller 🙂
En dus kunt u naar MVP kijken als een evolutie van MVC.
MVC is geweldig, maar het probleem is dat meestal de controller per weergave. Controller A weet hoe u de views A. instelt. Als u nu wilt bekijken A om gegevens van Model B weer te geven, hebt u controller a nodig om Model B te kennen B, of u hebt controller A nodig om een ​​object te ontvangen met een interface – wat is MVP alleen zonder de bindingen, of u moet de UI-setcode in Controller b herschrijven.
Conclusie – MVP en MVC zijn beide decouple van UI-patronen, maar MVP gebruikt meestal een bindingskader dat MVC eronder is. Dus MVP is op een hoger architectonisch niveau dan MVC en een wikkelpatroon hierboven van MVC.
16
Mijn nederige korte weergave: MVP is voor grote schalen en MVC voor kleine weegschalen. Met MVC, voel ik soms de V en de C kunnen een twee zijden van een enkele ondeelbare component worden gezien die nogal rechtstreeks aan M zijn gebonden, en ̩̩n valt onvermijdelijk hierop wanneer ze naar beneden gaan Рnaar kortere weegschalen, zoals UI-bedieningselementen en base-widgets. Op dit niveau van granulariteit is MVP weinig zin. Wanneer iemand integendeel naar grotere schubben gaat, wordt de juiste interface belangrijker, hetzelfde met eenduidige toewijzing van verantwoordelijkheden, en hier komt MVP.
Aan de andere kant, deze schaal regel van de duim, kan heel weinig gewicht wanneer het platform kenmerken voorstander van een soort van de betrekkingen tussen de componenten, zoals met het web, waar het lijkt makkelijker te implementeren MVC, meer dan MVP .
17
Er zijn vele versies van MVC, dit antwoord is over de oorspronkelijke MVC in Smalltalk. Kortom, het is
Dit gesprek Droidcon NYC 2017 – Clean app ontwerp met Architectuur Components verduidelijkt hij
18
Ik denk dat dit beeld door Erwin VanderValk (en de bijbehorende artikel ) de beste verklaring van MVC, MVP en MVVM hun gelijkenissen en hun verschillen. De artikel wordt niet weergegeven in de zoekmachine resultaten van zoekopdrachten op “MVC, MVP, en MVVM”, omdat de titel van het artikel niet de woorden “MVC” en “MVP” bevatten; maar het is de beste verklaring, denk ik.
(De artikelkomt ook overeen met wat oom Bob Martin zei in een van zijn lezingen: dat MVC oorspronkelijk was ontworpen voor de kleine UI-componenten, niet voor de architectuur van het systeem)
Antwoord 19
Het eenvoudigste antwoord is hoe de weergave samenwerkt met het model. In MVP wordt de weergave bijgewerkt door de presentator, die fungeert als intermediair tussen de weergave en het model. De presentator haalt de invoer uit de weergave, die de gegevens uit het model haalt en vervolgens de vereiste bedrijfslogica uitvoert en vervolgens de weergave bijwerkt. In MVC werkt het model de weergave rechtstreeks bij in plaats van terug te gaan via de controller.
Antwoord 20
Er is dezeleuke video van oom Bob waar hij kort uitlegt MVC& MVPaan het einde.
IMO, MVP is een verbeterde versie van MVC waarbij je in feite de zorg scheidt van wat je gaat laten zien (de gegevens) van hoe je gaat laten zien (het uitzicht). De presentator bevat een beetje de bedrijfslogica van uw gebruikersinterface, legt impliciet op welke gegevens moeten worden gepresenteerd en geeft u een lijst met domme weergavemodellen. En als het tijd is om de gegevens te tonen, sluit je eenvoudig je weergave (waarschijnlijk dezelfde id’s) aan op je adapter en stelt u de relevante weergavevelden in met behulp van die weergavemodellen met een minimale hoeveelheid code die wordt geïntroduceerd (alleen met behulp van setters). Het belangrijkste voordeel is dat u uw UI-bedrijfslogica kunt testen met veel/verschillende weergaven, zoals het weergeven van items in een horizontale of verticale lijst.
In MVC praten we via interfaces (grenzen) om verschillende lagen te lijmen. Een controller is een plug-in voor onze architectuur, maar heeft niet zo’n beperking om op te leggen wat te laten zien. In die zin is MVP een soort MVC met een concept waarbij views via adapters op de controller kunnen worden aangesloten.
Ik hoop dat dit beter helpt.
Antwoord 21
In een paar woorden,
- In MVC heeft View het UI-gedeelte, dat de controller aanroept, die op zijn beurt het model & model vuurt op zijn beurt gebeurtenissen terug om te bekijken.
- In MVP bevat View de gebruikersinterface en roept de presentator op voor het implementatiegedeelte. De presentator roept de weergave rechtstreeks op voor updates van het UI-gedeelte.
Model met bedrijfslogica wordt aangeroepen door de presentator en geen enkele interactie met de view. Dus hier doet de presentator het meeste werk 🙂
Antwoord 22
MVP
MVP staat voor Model – View- Presenter. Dit kwam begin 2007 tot een beeld toen Microsoft Smart Client Windows-applicaties introduceerde.
Een presentator treedt op als een toezichthoudende rol in MVP die gebeurtenissen en bedrijfslogica van modellen bekijken.
Bekijk gebeurtenisbinding wordt geïmplementeerd in de Presenter vanuit een weergave-interface.
De weergave is de initiator voor gebruikersinvoer en delegeert vervolgens de gebeurtenissen aan de presentator en de presentator handelt gebeurtenisbindingen af en haalt gegevens uit modellen.
Pluspunten:
De weergave heeft alleen een gebruikersinterface, geen logica
Hoge mate van testbaarheid
Nadelen:
Beetje ingewikkeld en meer werk bij het implementeren van gebeurtenisbindingen
MVC
MVC staat voor Model-View-Controller. Controller is verantwoordelijk voor het maken van modellen en het renderen van weergaven met bindende modellen.
Controller is de initiatiefnemer en beslist welke weergave wordt weergegeven.
Pluspunten:
Nadruk op het principe van één verantwoordelijkheid
Hoge mate van testbaarheid
Nadelen:
Soms te veel werklast voor controllers, als u meerdere weergaven in dezelfde controller probeert weer te geven.