Forskel mellem MVVM og MVP

Formålet med softwareudvikling er at bygge løsninger, der imødekommer behov og problemer for brugere og virksomheder. For at opnå dette kan forskellige teknologier og arkitekturmønstre lide Model-View-ViewModel (MVVM) og Model-View-Presenter (MVP) er brugt.

Som med alt, hvad der er fremstillet, er det første trin planlægnings- og designfasen. Softwaredesignprocessen kan være en specifikation baseret på det foretrukne teknologiske værktøjssæt, og det kan omfatte al aktivitet fra undfangelse - til - planlægning - til - implementering - til - opdateringer og ændringer.

Det dækker det lave niveau og det høje niveau arkitektonisk design, der er baseret på udvalgte arkitekturmønstre, og kortlægger genanvendelige løsninger ved hjælp af designmønstre.

Softwareapplikationsstruktur

Softwarearkitektur definerer en applikations struktur, der opfylder tekniske, operationelle og brugerkrav og henviser til, hvordan koden er organiseret og styret.

Beslutning om en softwareapplikations arkitektur er kritisk, da det ikke er en let, udskiftelig del af en applikation, der allerede er udviklet; derfor skal det arkitektoniske mønster besluttes, inden programmering påbegyndes.

Arkitektoniske mønstre adskiller sig noget fra designmønstre, da deres omfang er meget bredere ved at tackle flere tekniske problemer, såsom hardwareydelse og begrænsninger, og høj tilgængelighed. Eksempler på forskellige arkitekturmønstre er MVC, MVVM og MVP.

På den anden side er designmønstre formaliseret bedste praksis, der letter genanvendelig objektorienteret udvikling og er lettere at vedligeholde og ændre end en applikations arkitektur. 

Arkitekturmønstre

Model View Controller (MVC) var et af de første arkitektoniske mønstre udviklet til webapplikationer, der fik popularitet fra midten til slutningen af ​​halvfemserne, især med Java-samfundet.

De nyere rammer, såsom Django for Python og Rails (Ruby on Rails), har et stærkt fokus på hurtig implementering, hvilket er grunden til at MVC tager markedsandelen som den store attraktion inden for arkitektoniske mønstre.

Traditionelt indeholdt brugergrænsefladeudvikling en masse kode til at håndtere kompliceret logik, så arkitekturmønstre blev designet til at reducere koden på brugergrænseflade (UI) niveau, hvilket gør den mere 'ren' og håndterbar.

Så med MVC-mønsteret er en webapplikation sammensat af

• Model (data)
• Udsigt (interface til at se og manipulere data)
• Controller (operationer og handlinger udført på dataene)

Det Model håndterer data og forretningslogik, og der er der ingen afhængigheder mellem Model og Controller eller Udsigt.

Det Udsigt præsenterer dataene til brugeren i det understøttede format og det krævede layout, og når Controller modtager brugeranmodninger (for at hente data), det kalder de relevante ressourcer, der er nødvendige for at afslutte anmodningen.

Lad os anvende dette mønster til at opbygge en online boghandel.

Brugere kan søge, se, registrere, og købe bøger samt styre deres profiler og boglister. Når en bruger klikker på SCI-FI-kategorien, skal alle relaterede bøger vises som tilgængelige.

Det Controllere håndtere de handlinger, der administrerer bøgerne (liste, tilføj, vis osv.). Der kan være flere Controllere med en hoved Controller 'dirigere trafikken'.

I dette eksempel er Controller kaldes controller_books.php og Model (f.eks. model_books.php) håndterer data og logik relateret til bøgerne.

Endelig anderledes visninger vil være påkrævet, ligesom når du tilføjer bøger til onlinekurven, eller når du får vist bogdetaljerne med billeder og anmeldelser.

Det controller_books.php modtager handlingen (brugeranmodning) fra hovedmenuen Controller (f.eks. index.php). Det controller_books.php analyserer anmodningen og ringer til model_books.php (dataene) for at returnere listen over SCI-FI-bøger.

Ansvaret for Model er at give disse oplysninger ved hjælp af enhver anvendt logik (ved hjælp af søgefiltre). Det Controller derefter tager informationen og videregiver den til den relevante Udsigt (søgevisning, udskrivningsvisning, detaljeringsvisning osv.), og informationen præsenteres (via Udsigt) til den bruger, der initierede anmodningen.

Dette er det grundlæggende i MVC-mønsteret, der har udviklet gydevariationer af arkitekturmønstre, såsom Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC), og Model-View-Adapter (MVA) osv.

MVP-mønster

Model-View-Presenter (MVP)

Det MVP-mønster har eksisteret i et stykke tid og er en variant af MVC. Det blev designet specielt til testautomation, hvor målet var at øge mængden af ​​kode, der kan testes gennem automatisering, og mønsteret løser nogle problemer med præsentationslaget og isolerer forretningslogik fra UI.

Skærmen er visningen, de data, den viser, er modellen, og præsentanten kobler de to sammen.

MVP omfatter følgende komponenter med separat ansvar:

• Model (definerer de data, der skal vises)
• Udsigt (viser dataene fra modellen og ruter brugeranmodninger til præsentanten).
• Presenter (interagerer mellem visningen og modellen og kobler dem sammen)

Det Udsigt (en webside) viser og administrerer sidekontrollerne ved at videresende begivenheder (brugeranmodninger) til Presenter der blev indledt i Udsigt.

Det Presenter reagerer på disse begivenheder ved at læse og opdatere Model at ændre Udsigt og derfor Presenter s ansvaret er at binde Model og Udsigt.

Efter at have set på MVC og MVP mønstre, det fælles er begge har separate ansvarsområder for hver komponent, og de fremmer adskillelse mellem Udsigt (UI) og Model (data). Betydelige forskelle mellem disse mønstre er mere tydelige i, hvordan mønstrene implementeres.

MVP kan være et komplekst mønster at implementere til avancerede løsninger, men har bestemt store fordele, hvis det implementeres som en veludviklet løsning, skønt det ikke nødvendigvis er det passende valg til enkle løsninger.

MVVM-mønster

Model-View-ViewModel (MVVM)

Det MVVM mønster blev specifikt designet til Windows Presentation Foundation (WPF) og Microsoft Silverlight platforme, og det kan bruges på alle XAML [i] platforme.

WPF er et Microsoft-system, der gengiver brugergrænseflader i Windows-baserede programmer og først blev frigivet i .NET Framework 3.0.

MVVM blev forfinet fra MVC og i dette mønster, Udsigt er aktiv med opførsel, begivenheder og dataforbindelser og Udsigt synkroniseres med ViewModel (som muliggør adskillelse af præsentationen og afslører metoder og kommandoer til at styre og manipulere Model.

MVVM består af tre kernekomponenter:

• Model (repræsenterer dataene med validering og forretningslogik)
• Udsigt (Visningen er ansvarlig for at definere strukturen, layoutet og udseendet af det, brugeren ser på skærmen. Ideelt set er visningen defineret rent med XAML, med en begrænset kode bagved, der ikke indeholder forretningslogik. Tovejsdata- bindende mellem Udsigt og ViewModel til visningsindstillinger, der synkroniserer modellen og ViewModel med visningen)
• ViewModel (adskiller visningen fra modellen og afslører metoder og kommandoer til at manipulere dataene (model).

Det Udsigt modtager data fra ViewModel (gennem databinding og metoder) og ved kørselstidspunktet Udsigt ændres, når du reagerer på begivenheder i ViewModel.

Det ViewModel mægler mellem Udsigt og Model og håndterer Udsigt logik. Det interagerer med Model - at tage dataene fra Model og præsentere det for Udsigt at vise.

Disse komponenter er alle frakoblet fra hinanden, hvilket giver større fleksibilitet til at arbejde på dem uafhængigt, isolere enhedstest og udskifte dem uden at påvirke nogen anden komponent.

Denne struktur tillader Model og andre komponenter til at udvikle sig uafhængigt, så udviklere kan arbejde med forskellige aspekter af løsningen samtidigt. For eksempel, hvor designere arbejder på Udsigt, de genererer simpelthen dataprøver uden brug af adgang til de andre komponenter. Dette letter let redesign af brugergrænsefladen som Udsigt implementeres i XAML.

Som nævnt før med MVP, enkle løsninger behøver ikke arkitektur og designmønstre, som "Hello World!" er for grundlæggende til at følge ethvert mønster; efterhånden som flere funktioner, funktioner og komponenter introduceres, øges applikationens kompleksitet, og det øger også den mængde kode, der skal styres.

Sammenfattende

Siden starten af ​​brugergrænsefladeudvikling bliver designmønstre mere og mere populære for at gøre udviklingsprocessen lettere, applikationerne mere skalerbare og det letter lettere testning.

Illustreret forskel mellem MVP- og MVVM-mønstre:

• I begge MVP og MVVM, det Udsigt er indgangspunktet til applikationen
• I MVP, der er en-til-en-kortlægning mellem Udsigt og Presenter, hvor i MVVM, forholdet er en-til-mange mellem Udsigt og ViewModel.
• MVP bruges primært til Windows Forms og Windows Phone applikationer og MVVM er designet til Silverlight, WPF, Knockout / AngularJS osv.