Forskjellen mellom MVVM og MVP

Formålet med programvareutvikling er å bygge løsninger som adresserer behov og problemer for brukere og bedrifter. For å oppnå dette, har ulike teknologier og arkitekturmønstre som Model-View-ViewModel (MVVM) og Model-View-Presenter (MVP) er brukt.

Som med alt som er produsert, er det første trinnet planleggings- og designfasen. Programvareprosessprosessen kan være en spesifikasjon basert på det foretrukne teknologiske verktøyet, og det kan omfatte all aktivitet fra oppfattelse - til - planlegging - til - implementering - til - oppdateringer og modifikasjoner.

Den dekker arkitektonisk design på lavt nivå og på høyt nivå, basert på utvalgte arkitekturmønstre, og kartlegger gjenbrukbare løsninger ved hjelp av designmønstre.

Programvare applikasjonsstruktur

Programvarearkitektur definerer en applikasjonsstruktur som oppfyller tekniske, operasjonelle og brukerkrav og refererer til hvordan koden er organisert og administrert.

Å avgjøre om et program er arkitektur er kritisk fordi det ikke er en enkel, foranderlig del av et program som allerede er utviklet. Derfor må det arkitektoniske mønsteret avgjøres før programmering påbegynnes.

Arkitektoniske mønstre er noe annerledes enn designmønstre, da deres omfang er mye bredere ved å ta opp flere tekniske problemer som maskinvareytelse og begrensninger og høy tilgjengelighet. Eksempler på forskjellige arkitekturmønstre er MVC, MVVM og MVP.

På den annen side er designmønstre formaliserte beste praksis som letter gjenbrukbar objektorientert utvikling og er lettere å vedlikeholde og endre enn en applikasjons arkitektur. 

Arkitektur Mønstre

Modellvisningskontroller (MVC) var et av de første arkitektoniske mønstrene utviklet for webapplikasjoner, og ble populære fra midten til slutten av nittitallet, spesielt med Java-fellesskapet.

De nyere rammene, som Django for Python og Rails (Ruby on Rails), har sterkt fokus på rask distribusjon, og derfor tar MVC markedsandelen som den store attraksjonen i arkitektoniske mønstre.

Tradisjonelt inneholdt brukergrensesnittutvikling mye kode for å håndtere komplisert logikk, slik at arkitekturmønstre ble designet for å redusere koden på brukergrensesnittets (UI) nivå, noe som gjør det mer "rent" og håndterbart.

Så, med MVC-mønsteret, er en webapplikasjon sammensatt av

• Modell (data)
• Utsikt (grensesnitt for å vise og manipulere data)
• Controller (operasjoner og handlinger utført på dataene)

De Modell håndterer data og forretningslogikk og det er Nei avhengigheter mellom Modell og Controller eller Utsikt.

De Utsikt presenterer dataene til brukeren i formatet og formatet som støttes, og når Controller mottar brukerforespørsler (for å hente data), kaller det de relevante ressursene som trengs for å fullføre forespørselen.

La oss bruke dette mønsteret til å bygge en online bokhandel.

Brukere kan søke, vise, registrere og kjøpe bøker, samt administrere profiler og boklister. Når en bruker klikker på SCI-FI-kategorien, bør alle relaterte bøker vises som tilgjengelige.

De Controllers håndtere handlinger som håndterer bøkene (liste, legge til, se osv.). Det kan være flere Controllers med en hoved Controller 'styrer trafikken'.

For dette eksempelet, Controller er navngitt controller_books.php og Modell (for eksempel model_books.php) håndterer dataene og logikken knyttet til bøkene.

Til slutt, forskjellig Visninger vil være nødvendig, som når du legger til bøker i online-handlekurven eller når du ser bokdetaljer med bilder og anmeldelser.

De controller_books.php mottar handlingen (brukerforespørsel) fra hovedmenyen Controller (f.eks. index.php). De controller_books.php analyserer forespørselen og kaller model_books.php (dataene) for å returnere listen over SCI-FI-bøker.

Ansvaret for Modell er å gi den informasjonen ved hjelp av en logikk som ble brukt (ved hjelp av søkefiltre). De Controller tar deretter informasjonen og sender den til den aktuelle Utsikt (søkevisning, utskriftsvisning, detaljvisning etc) og informasjonen presenteres (via Utsikt) til brukeren som startet forespørselen.

Dette er grunnleggende for MVC-mønsteret, som har utviklet gytevarianter av arkitekturmønstre, for eksempel Model View Viewer (MVP), Model View-ViewModel (MVVM), Hierarchical-Model View-Controller (HMVC), og modell-visning-adapter (MVA) osv.

MVP-mønster

Model-View-Presenter (MVP)

De MVP mønster har eksistert en stund og er en variant av MVC. Den ble designet spesielt for testautomatisering, hvor målet var å øke mengden kode som kan testes gjennom automatisering, og mønsteret adresserer noen problemer med presentasjonslaget, isolerer forretningslogikk fra brukergrensesnittet.

Skjermen er View, dataene som vises, er modellen, og presentatøren knytter de to sammen.

MVP består av følgende komponenter med eget ansvar:

• Modell (definerer dataene som skal vises)
• Utsikt (viser dataene fra forespørsler fra modell og ruter til leverandøren).
• Presenter (samvirker mellom visning og modell og kroker dem sammen)

De Utsikt (en nettside) viser og styrer sidekontrollene ved å videresende hendelser (brukerforespørsler) til Presenter som ble initiert i Utsikt.

De Presenter reagerer på disse hendelsene ved å lese og oppdatere Modell å endre Utsikt og derfor, den presentatørens ansvaret er å binde Modell og Utsikt.

Etter å ha sett på MVC og MVP mønstre, commonality er begge har eget ansvar for hver komponent og de fremmer separasjon mellom Utsikt (Brukergrensesnitt) og Modell (data). Vesentlige forskjeller mellom disse mønstrene er tydeligere i hvordan mønstrene implementeres.

MVP kan være et komplekst mønster å implementere for avanserte løsninger, men har absolutt gode fordeler hvis det implementeres som en velfungerende løsning, selv om det ikke nødvendigvis kan være et passende valg for enkle løsninger.

MVVM Mønster

Model-View-ViewModel (MVVM)

De MVVM mønster ble spesielt utviklet for Windows Presentation Foundation (WPF) og Microsoft Silverlight-plattformer, og den kan brukes på alle XAML [i] plattformer.

WPF er et Microsoft-system som gir brukergrensesnitt i Windows-baserte programmer og ble først utgitt i .NET Framework 3.0.

MVVM ble raffinert fra MVC og i dette mønsteret, Utsikt er aktiv med atferd, hendelser og data bindende, og Utsikt synkroniseres med ViewModel (som muliggjør adskillelse av presentasjonen og avslører metoder og kommandoer for å administrere og manipulere Modell.

MVVM består av tre kjernekomponenter:

• Modell (representerer dataene med validering og forretningslogikk)
• Utsikt (Visningen er ansvarlig for å definere strukturen, oppsettet og utseendet til hva brukeren ser på skjermen. Ideelt sett er visningen bare definert med XAML, med en begrenset kode bak det som ikke inneholder forretningslogikk. Toveis data- bindende mellom Utsikt og ViewModel til displayenables synkronisere modellen og ViewModel med visningen)
• ViewModel (skiller visningen fra modellen, og avslører metoder og kommandoer for å manipulere dataene (modell).

De Utsikt mottar data fra ViewModel (gjennom data-binding og metoder), og ved kjøretid, den Utsikt vil endres når du svarer på hendelser i ViewModel.

De ViewModel formidler mellom Utsikt og Modell og håndterer Utsikt logikk. Det samhandler med Modell - tar data fra Modell og presentere den til Utsikt å vise.

Disse komponentene er alle koblet fra hverandre, slik at det blir større fleksibilitet til å jobbe på dem selvstendig, isolere enhetstesting og bytte dem ut uten å påvirke noen annen komponent.

Denne strukturen tillater Modell og andre komponenter for å utvikle seg selvstendig, slik at utviklere kan jobbe på ulike sider av løsningen samtidig. For eksempel, hvor designere jobber på Utsikt, de genererer ganske enkelt data prøver uten å ha tilgang til de andre komponentene. Dette muliggjør enkel redesign av brukergrensesnittet som Utsikt er implementert i XAML.

Som nevnt tidligere med MVP, enkle løsninger vil ikke trenge arkitektur og design mønstre, som "Hello World!" er for grunnleggende for å følge noen mønster; Men etter hvert som flere funksjoner, funksjoner og komponenter blir introdusert, øker programmets kompleksitet og det gjør også koden som må administreres.

Oppsummert

Siden begynnelsen av brukergrensesnittutvikling blir designmønstre stadig mer populære for å gjøre utviklingsprosessen lettere, applikasjonene skalerbare og det letter enklere testing.

Illustrert forskjell mellom MVP- og MVVM-mønstrene:

• I begge MVP og MVVM, de Utsikt er inngangspunktet for søknaden
• I MVP, Det er en-til-en kartlegging mellom Utsikt og Presenter, hvor i MVVM, forholdet er en-til-mange mellom Utsikt og ViewModel.
• MVP brukes primært til Windows Forms og Windows Phone applikasjoner og MVVM er designet for Silverlight, WPF, Knockout / AngularJS, etc.