Forskel mellem MVVM og MVP Forskel mellem

Formålet med softwareudvikling at opbygge løsninger, der adresserer behov og problemer for brugere og virksomheder. For at opnå dette bruges forskellige teknologier og arkitekturmønstre som Model-View-ViewModel (MVVM) og Model-View-Presenter (MVP) .

Som med alt, hvad der fremstilles, er det første skridt planlægnings- og designfasen. Softwaredesignprocessen kan være en specifikation baseret på det foretrukne teknologiværktøjssæt, og det kan omfatte al aktivitet fra koncept - til - planlægning - til - implementering - til - opdateringer og modifikationer.

Det dækker arkitektonisk design på lavt niveau og på højt plan baseret på udvalgte arkitekturmønstre og kortlægger genanvendelige løsninger ved hjælp af designmønstre.

Software Application Structure

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

Beslutning om softwareprogrammets arkitektur er kritisk, da det ikke er en let, omskiftelig del af et program, der allerede er udviklet. Derfor skal det arkitektoniske mønster afgøres inden nogen programmering påbegyndes.

Arkitektoniske mønstre er noget anderledes end designmønstre, da deres anvendelsesområde er meget bredere ved at håndtere flere tekniske problemer som hardware ydeevne 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 formaliserede bedste praksis, som letter genanvendelig objektorienteret udvikling og er lettere at vedligeholde og ændre end en applikations arkitektur.

->

Arkitektur Mønstre

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

De nyere rammer, som Django for Python og Rails (Ruby on Rails), har et stærkt fokus på hurtig implementering, og derfor tager MVC markedsandelen som den store attraktion i arkitektoniske mønstre.

Traditionelt indeholdt brugergrænsefladeudvikling en masse kode til håndtering af kompliceret logik, så arkitekturmønstre blev designet til at reducere koden på brugergrænsefladen (UI), hvilket gør det mere 'rent' og håndterbart.

Så med MVC-mønsteret består en webapplikation af

• Model (data)
• Vis (interface til visning og manipulation af data)
• Controller og handlinger udført på data)

Model håndterer data- og forretningslogik, og der er nej afhængigheder mellem Model og Controller < eller Vis .

Vis 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), kalder den de relevante ressourcer til rådighed at fuldføre 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 administrere deres profiler og boglister. Når en bruger klikker på SCI-FI-kategorien, skal alle relaterede bøger vises som ledige.

Controllers håndter de handlinger, der styrer bøgerne (liste, tilføj, se osv.). Der kan være flere Controllers med en hoved Controller 'styring af trafikken'. I dette eksempel benævnes

Controller controller_books. php og Model (f.eks. model_books. php) håndterer data og logik relateret til bøgerne. Endelig vil forskellige

Visninger blive påkrævet, som når du tilføjer bøger til online-vognen eller når du ser bogdetaljer med billeder og anmeldelser. De

controller_books. php modtager handlingen (brugeranmodning) fra hovedmenuen Controller (fx indeks. php ). De controller_books. php analyserer anmodningen og kalder model_bøgerne. php (dataene) for at returnere listen over SCI-FI bøger. Ansvaret for

Model er at give denne information ved hjælp af en logik, der blev anvendt (ved hjælp af søgefiltre). Controller tager derefter informationen og sender den til det relevante Vis (søgevisning, udskriftsvisning, detaljeret visning osv.) Og oplysningerne præsenteres (via Vis >) til den bruger, der indledte anmodningen. Dette er fundamentet for MVC-mønsteret, som 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) mv. MVP Mønster

Model-View-Presenter (MVP)

MVP-mønsteret

har eksisteret i et stykke tid og er en variant af MVC. Det blev designet specielt til testautomatisering, 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, der isolerer forretnings logik fra brugergrænsefladen. Skærmen er visningen, de data, der vises, er modellen, og præsentanten hakker de to sammen. MVP

omfatter følgende komponenter med særskilte ansvarsområder:

Model (definerer de data, der skal vises)

• Se (viser dataene fra model- og ruteforespørgsler til presenter).
• Presenter (interagerer mellem Vis og Model og samler dem sammen)
• Vis

(en webside) viser og styrer sidekontrollerne ved at videresende begivenheder (brugeranmodninger) til Presenter , der blev indledt i Vis . Presenter

reagerer på disse begivenheder ved at læse og opdatere Model for at ændre Vis og derfor er ansvaret for Presenter at binde Model og Se . Efter at have set på MVC

og MVP -mønstrene, har commonality begge særskilte ansvar for hver komponent, og de fremmer adskillelse mellem View (UI) og Model (data). Væsentlige forskelle mellem disse mønstre er mere tydelige i, hvordan mønstrene implementeres. MVP kan være et komplekst mønster at implementere for avancerede løsninger, men har helt sikkert store fordele, hvis det implementeres som en veldesignet løsning, selvom det ikke nødvendigvis er det rette valg til enkle løsninger.

MVVM mønster

Model-View-ViewModel (MVVM)

MVVM mønster blev specielt designet til Windows Presentation Foundation (WPF) og Microsoft Silverlight platforme, og det kan være bruges på alle XAML [i] platforme. WPF er et Microsoft-system, der giver brugergrænseflader i Windows-baserede programmer og blev først udgivet i.NET Framework 3. 0.

MVVM

blev raffineret fra MVC og i dette mønster Vis er aktiv med adfærd, begivenheder og dataindbinding, og Vis synkroniseres med ViewModel (som gør det muligt at adskille præsentationen og udsætte metoder og kommandoer til at styre og manipulere Model . MVVM

består af tre kernekomponenter: Model

• (repræsenterer data med validering og forretnings logik) Se > (Visningen er ansvarlig for at definere strukturen, layoutet og udseendet af, hvad brugeren ser på skærmen. Ideelt set er visningen udelukkende defineret med XAML, med en begrænset kode bag, der ikke indeholder forretnings logik. Tovejs data -binding mellem
• View og ViewModel til displayenables synkronisering af modellen og ViewModel med View) ViewModel (adskiller visningen fra e Model, og udsætter metoder og kommandoer til manipulation af data (Model).
• Vis

modtager data fra ViewModel (gennem databinding og metoder), og i løbet af tiden vil Visning ændres, når man svarer på begivenheder i den ViewModel . ViewModel

formidler mellem Vis og Model og håndterer Vis logikken. Det interagerer med Model - tager data fra Model og præsenterer det til Vis for at vise. Disse komponenter er alle afkoblet fra hinanden, hvilket giver større fleksibilitet til at arbejde uafhængigt af dem, isolere enhedsprøvning og bytte dem ud uden at påvirke andre komponenter. Denne struktur gør det muligt for

Model

og andre komponenter at udvikle sig selvstændigt, så udviklere kan arbejde på forskellige aspekter af løsningen samtidigt. For eksempel, hvor designere arbejder på Vis , genererer de simpelthen dataprøver uden at have adgang til de andre komponenter. Dette letter let redesign af brugergrænsefladen, da View implementeres i XAML. Som nævnt før med MVP, ville simple løsninger ikke have brug for arkitektur og designmønstre, som "Hello World!"Er for grundlæggende til at følge ethvert mønster; Men som flere funktioner, funktioner og komponenter introduceres, øges applikationens kompleksitet, og det gør også mængden af ​​kode, der skal styres. I sammendrag Siden starten af ​​brugergrænsefladeudvikling bliver designmønstre stadig mere populære for at gøre udviklingsprocessen nemmere, applikationerne skalerbar og letter lettere.

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

I både

MVP

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