Verschil tussen MVVM en MVP Verschil tussen

Het doel van softwareontwikkeling is om oplossingen te bouwen die tegemoetkomen aan behoeften en problemen voor gebruikers en bedrijven. Hiervoor worden verschillende technologieën en architectuurpatronen zoals Model-View-ViewModel (MVVM) en Model-View-Presenter (MVP) 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-toepassingsstructuur

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

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 objectgerichte ontwikkeling mogelijk maken en eenvoudiger te onderhouden en te veranderen zijn dan de architectuur van een applicatie.

Architectuurpatronen

Model View Controller (MVC) was een van de eerste architecturale patronen die werden ontwikkeld voor webtoepassingen en won aan populariteit van midden 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 snelle inzetbaarheid. Daarom neemt MVC het marktaandeel over als de grootste attractie in architecturale patronen.

Traditioneel bevat de ontwikkeling van de gebruikersinterface veel code om ingewikkelde 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 webtoepassing uit

• Model (gegevens)
• Beeld (interface om gegevens weer te geven en te manipuleren)
• Controller (bewerkingen en acties uitgevoerd op de gegevens)

Het Model verwerkt gegevens en bedrijfslogica en er zijn geen afhankelijkheden tussen de Model en de Controller < of View . De

Weergave presenteert de gegevens aan de gebruiker in de ondersteunde indeling en vereiste lay-out en wanneer de Controller gebruikersverzoeken ontvangt (om gegevens op te halen), roept deze de relevante benodigde bronnen op om het verzoek te voltooien. Laten we dit patroon toepassen om een ​​online boekwinkel te bouwen.

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

De

controllers behandelen de acties die de boeken beheren (lijst, toevoegen, bekijken, enz.). Er kunnen meerdere controllers zijn met één hoofd controller 'die het verkeer regisseren'. Voor dit voorbeeld heeft de

Controller de naam controller_books. php en het model (bijvoorbeeld model_books. php) handelt de gegevens en logica af die betrekking hebben op de boeken. Ten slotte zijn er verschillende

weergaven vereist, zoals bij het toevoegen van boeken aan de online winkelwagen of bij het bekijken van de boekdetails met afbeeldingen en recensies. Het

controller_books. php ontvangt de actie (gebruikersverzoek) van de hoofd Controller (bijv. index. php ). De controller_books. php analyseert het verzoek en roept de modelboeken aan. php (de gegevens) om de lijst met SCI-FI-boeken te retourneren. De verantwoordelijkheid van het

model is om die informatie te verstrekken, met behulp van elke toegepaste logica (met behulp van zoekfilters). De Controller neemt de informatie vervolgens en geeft deze door aan de relevante View (zoekweergave, afdrukweergave, detailweergave, enz.) En de informatie wordt gepresenteerd (via de View >) naar de gebruiker die het verzoek heeft gestart. Dit zijn de grondbeginselen van het MVC-patroon, waarin zich voortplantingsvariaties van architectuurpatronen hebben ontwikkeld, zoals Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC), en Model-View-Adapter (MVA), enz. MVP-patroon

Model-View-Presenter (MVP)

Het

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 te vergroten die kan worden getest door automatisering, en het patroon lost een aantal problemen op met de presentatielaag en isoleert bedrijfslogica van de gebruikersinterface. Het scherm is de weergave, de gegevens die worden weergegeven, zijn het model en de presentator haakt de twee samen. MVP

bevat de volgende componenten met afzonderlijke verantwoordelijkheden:

Model (definieert de weer te geven gegevens)

• View (geeft de gegevens van het model weer en routeert gebruikersverzoeken naar de Presentator).
• Presentator (communiceert tussen de weergave en het model en koppelt ze aan elkaar)
• De weergave

(een webpagina) toont en beheert de paginabesturing door gebeurtenissen (gebruikersverzoeken) door te sturen naar de Presentator die zijn gestart in Weergave . De Presenter

reageert op deze gebeurtenissen door het model te lezen en bij te werken om de weergave te wijzigen en daarom is de presentator verantwoordelijk voor om het model en weergave te binden. Nadat u MVC

en MVP -patronen hebt bekeken, heeft de overeenkomst beide afzonderlijke verantwoordelijkheden voor elk onderdeel en wordt de scheiding tussen View (UI) en Model (data). Significante verschillen tussen deze patronen zijn duidelijker in hoe de patronen worden geïmplementeerd. MVP is mogelijk een complex patroon om te implementeren voor geavanceerde oplossingen, maar heeft zeker grote voordelen als het wordt geïmplementeerd als een goed ontworpen oplossing, hoewel het niet per se de juiste keuze is voor eenvoudige oplossingen.

MVVM-patroon Model-View-ViewModel (MVVM)

Het

MVVM

-patroon is speciaal ontworpen voor Windows Presentation Foundation (WPF) en Microsoft Silverlight-platforms, en het kan gebruikt op alle XAML [i] platforms. WPF is een Microsoft-systeem dat gebruikersinterfaces weergeeft in Windows-programma's en voor het eerst wordt uitgebracht in. NET Framework 3. 0. MVVM

is verfijnd van

MVC en in dit patroon, de weergave is actief met gedrag, gebeurtenissen en databinding en de weergave wordt gesynchroniseerd met het weergavemodel (waarmee de presentatie kan worden gescheiden en methodes kunnen worden weergegeven) en opdrachten voor het beheren en manipuleren van het Model . MVVM bestaat uit drie hoofdcomponenten:

Model (vertegenwoordigt de gegevens met validatie en bedrijfslogica)

• View > (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 wordt de weergave uitsluitend gedefinieerd met XAML, met een beperkte code achter die geen bedrijfslogica bevat. -bindend tussen het View
• en ViewModel om displayenables te synchroniseren, het Model en het ViewModel te synchroniseren met de View) ViewModel (scheidt de View van th e Model, en stelt methoden en opdrachten voor om de gegevens te manipuleren (Model). De
• weergave ontvangt gegevens van het

weergavemodel (via gegevensbinding en methoden) en tijdens runtime verandert de weergave bij het reageren op gebeurtenissen in de ViewModel . Het ViewModel bemiddelt tussen het

View en Model en verwerkt de View -logica. Het werkt samen met het model - neemt de gegevens van het model en presenteert het aan de weergave om weer te geven. Deze componenten zijn allemaal ontkoppeld van elkaar, waardoor ze flexibeler kunnen werken om ze onafhankelijk uit te voeren, unittests te isoleren en ze uit te wisselen, zonder een ander onderdeel te beïnvloeden. Met deze structuur kunnen het model

en andere componenten onafhankelijk evolueren, waardoor ontwikkelaars gelijktijdig aan verschillende aspecten van de oplossing kunnen werken. Wanneer ontwerpers bijvoorbeeld aan

Weergave werken, genereren ze eenvoudig gegevensvoorbeelden zonder toegang tot de andere componenten. Dit vergemakkelijkt een eenvoudig herontwerp van de gebruikersinterface wanneer de weergave wordt geïmplementeerd in XAML. Zoals eerder vermeld met MVP , hebben eenvoudige oplossingen geen architectuur- en ontwerppatronen nodig, 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.

Samenvattend 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 het testen. Geïllustreerd verschil tussen de MVP- en MVVM-patronen:

In zowel

MVP

en

• MVVM is de weergave het beginpunt voor de toepassing > In MVP is er één-op-één toewijzing tussen View
• en Presenter , waarbij in MVVM de relatie één is -tot-many tussen de View en ViewModel . MVP wordt voornamelijk gebruikt voor Windows Forms en Windows Phone-toepassingen en MVVM is ontworpen voor Silverlight, WPF, Knockout / AngularJS, etc.