Programmering

Udforskning af MVC-, MVP- og MVVM-designmønstre

Brugergrænsefladen indeholder ofte en masse rodet kode primært på grund af den komplicerede logik, den har brug for at håndtere. Præsentationsmønstrene designes primært med et mål i tankerne, reducerer den komplekse kode i præsentationslaget og gør koden i brugergrænsefladen ren og håndterbar. I dette indlæg vil jeg præsentere en diskussion om MVC-, MVP- og MVVM-designmønstre og fremhæve, hvornår man skal være det valgte design frem for den anden.

Model View-controller

Model View Controller (almindeligvis kendt som MVC) rammer hjælper dig med at opbygge applikationer, der er lettere at teste og vedligeholde. Den består af tre hovedkomponenter, nemlig:

  1. Model - dette er det lag, der repræsenterer applikationens data
  2. Vis - dette repræsenterer præsentationen eller brugergrænsefladelaget
  3. Controller - dette lag indeholder typisk virksomhedens logik i din applikation

Det primære mål med MVC-mønsteret er adskillelse af bekymringer for at lette testbarhed. Model View Controller designmønsteret giver dig mulighed for at isolere bekymringerne og gør din applikations kode lettere at teste og vedligeholde. I et typisk MVC-design ankommer anmodningen først til controlleren, der binder modellen med den tilsvarende visning. I MVC-designmønsteret bruger visningen og controlleren strategidesign, og visningen og modellen synkroniseres ved hjælp af observatørdesignet. Derfor kan vi sige, at MVC er et sammensat mønster. Controlleren og visningen er løst koblet, og en controller kan bruges af flere visninger. Visningen abonnerer på ændringer i modellen.

Model View-præsentator

MVP (Model View Presenter) designmønsteret består også af tre komponenter - modellen, visningen og præsentanten. I MVP-designmønsteret erstattes controlleren (i MVC) af præsentatoren. I modsætning til MVC-designmønsteret henviser præsentatoren tilbage til visningen, som det er lettere at spotte, og enhedstest af applikationer, der udnytter MVP-designmønsteret over MVC-designmønsteret, er meget lettere. I MVP-mønsteret manipulerer præsentatoren modellen og opdaterer også visningen. Der er to variationer af dette design. Disse inkluderer følgende.

  1. Passiv visning - i denne strategi er visningen ikke opmærksom på modellen, og præsentanten opdaterer visningen for at afspejle ændringerne i modellen.
  2. Supervising Controller - i denne strategi interagerer visningen direkte med modellen for at binde data til datakontrollerne uden indblanding fra præsentatoren. Præsentanten er ansvarlig for opdatering af modellen. Det manipulerer kun visningen, hvis det er nødvendigt - hvis du har brug for en kompleks brugergrænsefladelogik, der skal udføres.

Mens begge disse varianter fremmer testbarheden af ​​præsentationslogikken, foretrækkes den passive visningsvariant frem for den anden variant (kontrolstyring) for så vidt angår testbarhed primært fordi du har al den opdaterede visningslogik inde i præsentatoren.

MVP-designmønsteret foretrækkes frem for MVC, når din applikation skal understøtte flere brugergrænsefladeteknologier. Det foretrækkes også, hvis du har en kompleks brugergrænseflade med en masse brugerinteraktion. Hvis du gerne vil have en automatiseret enhedstest på brugergrænsefladen til din applikation, er MVP-designmønsteret velegnet og foretrukket frem for det traditionelle MVC-design.

Model - Vis - ViewModel (MVVM)

Model - View - ViewModel (MVVM) er en variation af Martin Fowlers præsentationsmodel designmønster. MVVM er en forbedring af det populære MVC-design, og ViewModel i MVVM bruges til at lette præsentationsseparation. I MVVM lagres logikken i præsentatoren, og udsigten er fuldstændig isoleret fra modellen. Mens præsentatoren ikke er opmærksom på visningen, er visningen opmærksom på præsentatoren - præsentatoren i MVVM bruges til at repræsentere en abstrakt visning af brugergrænsefladen. En passiv opfattelse indebærer, at udsigten ikke har noget kendskab til modellen. I MVVM-designmønsteret er visningen aktiv og indeholder adfærd, hændelser og databindende information. Bemærk, at visningen i MVVM ikke er ansvarlig for styring af tilstandsoplysningerne - visningen er ret synkroniseret med visningsmodellen. Visningsmodellen i MVVM er ansvarlig for præsentationsadskillelse og udsætter metoder og kommandoer til at styre tilstanden for en visning og manipulere modellen.

Hvordan kommunikerer udsigten og synsmodellen i MVVM? Visningen og visningsmodellen i MVVM kommunikerer ved hjælp af metoder, egenskaber og begivenheder. Den tovejs databinding eller tovejs databinding mellem visningen og visningsmodellen sikrer, at modellerne og egenskaberne i visningsmodellen er synkroniseret med visningen. MVVM-designmønsteret er velegnet til applikationer, der har brug for support til tovejs databinding.

$config[zx-auto] not found$config[zx-overlay] not found