Verschil tussen MVVM en MVP

Het doel van softwareontwikkeling is om oplossingen te ontwikkelen die tegemoetkomen aan behoeften en problemen voor gebruikers en bedrijven. Om dit te bereiken, verschillende technologieën en architectuurpatronen zoals Model-View-ViewModel (MVVM) en Model-View-Presenter (MVP) worden gebruikt.

Zoals met alles dat wordt gefabriceerd, is de eerste stap de plannings- en ontwerpfase. Het software ontwerpproces kan een specificatie zijn gebaseerd op de geprefereerde technologische tool-set, en het kan alle activiteiten omvatten van conceptie tot planning tot implementatie en updates..

Het behandelt het architectuurontwerp op laag niveau en op hoog niveau, gebaseerd op geselecteerde architectuurpatronen, en brengt herbruikbare oplossingen in kaart met behulp van ontwerppatronen.

Software applicatie structuur

Software-architectuur definieert de structuur van een applicatie die voldoet aan technische, operationele en gebruikersvereisten en verwijst naar hoe de code wordt georganiseerd en beheerd.

Het beslissen over de architectuur van een softwaretoepassing is van cruciaal belang, omdat het geen gemakkelijk, veranderlijk onderdeel is van een applicatie die al is ontwikkeld; daarom moet het architecturale patroon worden bepaald voordat een programmering begint.

Architecturale patronen wijken enigszins af van ontwerppatronen omdat de reikwijdte veel breder is door meer technische problemen aan te pakken, zoals hardwareprestaties en -beperkingen, en hoge beschikbaarheid. Voorbeelden van verschillende architectuurpatronen zijn MVC, MVVM en MVP.

Anderzijds zijn ontwerppatronen geformaliseerde best practices die herbruikbare objectgeoriënteerde ontwikkeling mogelijk maken en eenvoudiger te onderhouden en te veranderen zijn dan de architectuur van een toepassing. 

Architectuurpatronen

Model View Controller (MVC) was een van de eerste architecturale patronen die werden ontwikkeld voor webapplicaties, en won aan populariteit van medio tot eind jaren negentig, vooral bij de Java-gemeenschap.

De nieuwere frameworks, zoals Django voor Python en Rails (Ruby on Rails), hebben een sterke focus op een snelle implementatie. Daarom neemt MVC het marktaandeel over als de grootste attractie in architecturale patronen.

Traditioneel bevat de ontwikkeling van de gebruikersinterface veel code om gecompliceerde logica te verwerken, dus werden architectuurpatronen ontworpen om de code op het niveau van de gebruikersinterface (UI) te verminderen, waardoor deze meer 'schoon' en beheersbaar werd.

Dus, met het MVC-patroon, bestaat een webapplicatie

• Model (gegevens)
• Uitzicht (interface om gegevens te bekijken en te manipuleren)
• controleur (bewerkingen en acties uitgevoerd op de gegevens)

De Model handelt gegevens en bedrijfslogica aan en er zijn Nee afhankelijkheden tussen de Model en de controleur of Uitzicht.

De Uitzicht presenteert de gegevens aan de gebruiker in het ondersteunde formaat en de vereiste lay-out, en wanneer de controleur ontvangt gebruikersverzoeken (om gegevens op te halen), het roept de relevante bronnen op die nodig zijn om het verzoek te voltooien.

Laten we dit patroon toepassen op het bouwen van een online boekwinkel.

Gebruikers kunnen boeken zoeken, bekijken, registreren en kopen, maar ook hun profielen en boekenlijsten beheren. Wanneer een gebruiker op de SCI-FI-categorie klikt, moeten alle gerelateerde boeken worden weergegeven als beschikbaar.

De Controllers omgaan met de acties die de boeken beheren (lijst, toevoegen, bekijken, enz.). Er kan meerdere zijn Controllers met één hoofd controleur 'het verkeer leiden'.

Voor dit voorbeeld, de controleur heet controller_books.php en de Model (bijvoorbeeld model_books.php) omgaat met de gegevens en logica met betrekking tot de boeken.

Ten slotte, anders Keer bekeken vereist, zoals bij het toevoegen van boeken aan de online winkelwagen of bij het bekijken van de boekdetails met afbeeldingen en recensies.

De controller_books.php ontvangt de actie (gebruikersverzoek) van de main controleur (bijv. index.php). De controller_books.php analyseert het verzoek en roept het model_books.php (de gegevens) om de lijst met SCI-FI-boeken te retourneren.

De verantwoordelijkheid van de Model is om die informatie te verstrekken, met behulp van elke logica die is toegepast (met behulp van zoekfilters). De controleur neemt vervolgens de informatie en geeft deze door aan de betreffende Uitzicht (zoekweergave, afdrukweergave, detailweergave, enz.) en de informatie wordt gepresenteerd (via de Uitzicht) aan de gebruiker die het verzoek heeft gestart.

Dit zijn de grondbeginselen van het MVC-patroon, dat zich ontwikkelde spawningvariaties van architectuurpatronen heeft ontwikkeld, zoals de Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hiërarchisch-Model-View-Controller (HMVC), en Model-View-Adapter (MVA), enz.

MVP-patroon

Model-View-Presenter (MVP)

De MVP-patroon bestaat al een tijdje en is een variant van MVC. Het is speciaal ontworpen voor testautomatisering waarbij het doel was om de hoeveelheid code die kan worden getest door automatisering te vergroten, en het patroon lost een aantal problemen op met de presentatielaag, waardoor bedrijfslogica wordt geïsoleerd van de UI.

Het scherm is de weergave, de gegevens die worden weergegeven, zijn het model en de presentator haakt de twee samen.

MVP bestaat uit de volgende componenten met afzonderlijke verantwoordelijkheden:

• Model (definieert de gegevens die moeten worden weergegeven)
• Uitzicht (geeft de gegevens van het model weer en routeert gebruikersverzoeken naar de presentator).
• Presentator (interageert tussen de weergave en het model en koppelt ze aan elkaar)

De Uitzicht (een webpagina) toont en beheert de paginabesturing door gebeurtenissen (gebruikersverzoeken) door te sturen naar de Presentator die werden geïnitieerd in de Uitzicht.

De Presentator reageert op deze gebeurtenissen door het te lezen en bij te werken Model om het te veranderen Uitzicht en daarom, de Presenter's verantwoordelijkheid is om de Model en Uitzicht.

Na het kijken naar MVC en MVP patronen, de overeenkomstigheid heeft beide afzonderlijke verantwoordelijkheden voor elke component en ze bevorderen de scheiding tussen de Uitzicht (UI) en Model (gegevens). Significante verschillen tussen deze patronen zijn duidelijker in hoe de patronen worden geïmplementeerd.

MVP kan een complex patroon zijn om te implementeren voor geavanceerde oplossingen, maar heeft zeker grote voordelen als het wordt geïmplementeerd als een goed ontworpen oplossing, hoewel het misschien niet de juiste keuze is voor eenvoudige oplossingen.

MVVM-patroon

Model-View-ViewModel (MVVM)

De MVVM patroon is speciaal ontworpen voor Windows Presentation Foundation (WPF) en Microsoft Silverlight-platforms en kan voor iedereen worden gebruikt XAML [i] platforms.

WPF is een Microsoft-systeem dat gebruikersinterfaces weergeeft in Windows-programma's en voor het eerst werd uitgebracht in .NET Framework 3.0.

MVVM werd verfijnd van MVC en in dit patroon, de Uitzicht is actief met gedrag, gebeurtenissen en gegevensbinding, en de Uitzicht synchroniseert met de ViewModel (die de scheiding van de presentatie mogelijk maakt en methoden en opdrachten blootlegt om het te beheren en te manipuleren Model.

MVVM bestaat uit drie kerncomponenten:

• Model (vertegenwoordigt de gegevens met validatie en bedrijfslogica)
• Uitzicht (De weergave is verantwoordelijk voor het definiëren van de structuur, lay-out en uiterlijk van wat de gebruiker op het scherm ziet.In het ideale geval is de weergave puur gedefinieerd met XAML, met een beperkte code achter die geen bedrijfslogica bevat.twee manier gegevens- binding tussen de Uitzicht en ViewModel naar weergavemogelijkheden synchroniseren van het model en het ViewModel met de weergave)
• ViewModel (scheidt de weergave van het model en stelt methoden en opdrachten bloot om de gegevens te manipuleren (model).

De Uitzicht ontvangt gegevens van de ViewModel (via data-binding en methoden), en tijdens runtime, de Uitzicht zal veranderen bij het reageren op gebeurtenissen in de ViewModel.

De ViewModel bemiddelt tussen de Uitzicht en Model en behandelt de Uitzicht logica. Het werkt samen met de Model - de gegevens van de Model en het presenteren aan de Uitzicht weergeven.

Deze componenten zijn allemaal ontkoppeld van elkaar, waardoor ze flexibeler kunnen werken om ze onafhankelijk uit te voeren, unit-testen te isoleren en ze uit te wisselen, zonder invloed op andere componenten.

Deze structuur maakt het mogelijk Model en andere componenten om zelfstandig te evolueren, waardoor ontwikkelaars gelijktijdig aan verschillende aspecten van de oplossing kunnen werken. Waar ontwerpers bijvoorbeeld aan werken Uitzicht, ze genereren eenvoudig gegevenssamples zonder toegang tot de andere componenten. Dit vergemakkelijkt een eenvoudig herontwerp van de gebruikersinterface als de Uitzicht is geïmplementeerd in XAML.

Zoals eerder vermeld met MVP, eenvoudige oplossingen zouden geen architectuur en ontwerppatronen nodig hebben, zoals "Hallo wereld!" is te basaal om elk patroon te volgen; Naarmate echter meer functies, functies en componenten worden geïntroduceerd, neemt de complexiteit van de toepassing toe en neemt ook de hoeveelheid code die moet worden beheerd toe..

Samengevat

Sinds het begin van de ontwikkeling van de gebruikersinterface, worden ontwerppatronen steeds populairder om het ontwikkelingsproces gemakkelijker te maken, de toepassingen meer schaalbaar en vergemakkelijkt het testen.

Geïllustreerd verschil tussen de MVP- en MVVM-patronen:

• In beide MVP en MVVM, de Uitzicht is het toegangspunt tot de applicatie
• In MVP, er is een-op-een afbeelding tussen de Uitzicht en Presentator, waar in MVVM, de relatie is one-to-many tussen de Uitzicht en ViewModel.
• MVP wordt voornamelijk gebruikt voor Windows Forms en Windows Phone-applicaties en MVVM is ontworpen voor Silverlight, WPF, Knockout / AngularJS, enz.