tässä artikkelissa, löydämme jotain MVP kuvio, se on peritty MVC kuvio. Mutta ehdottomasti, se on joitakin muutoksia verrattuna MVC kuvio. Niin, ymmärrämme, miten käyttää sitä, miten erottaa MVC kuvio ja MVP kuvio.

aloitetaan.

VP-kuvion määritelmä

analyysi-ongelma

MVP-kuvio on sama kuin MVC kuvio. Mutta MVP: tä käytetään estämään joitakin MVC-kuvion haittoja, kuten:

• MVC-kuviossa näkymä ja malli voivat olla vuorovaikutuksessa keskenään. Niin, me yleensä validoida tietoja mallin tai käyttää datalogiikkaa näköpiirissä. Se vaikeuttaa automaattista yksikkötestausta.
• sillä on merkitystä vakuuden kannalta.

MVVM-kuvion määritelmä

wikipedia.com, meillä on MVP-kuvion määritelmä:

MVP pattern is a derivation of the Model-View-Controller (MVC) architectural pattern, and is used mostly for building user interfaces.In MVP, the presenter assumes the functionality of the middle-man.In MVP, all presetation logic is pushed to the presenter.

ja MVP-kuvio sai alkunsa 1990-luvun alussa Taligentissa, Applen, IBM: n ja Hewlett-Packardin yhteisyrityksessä.

alla on MVP-kuvion kunkin osan sisältö.

• mallissa on kokonaisuuksia ja palveluita.

  entiteettejä käytetään tietokannassa taulukon kanssa yhdistettävien tietojen sisältämiseen joitakin muita syitä hyödyntäen.

  palvelut, voidaan käyttää DAO-mallia, tai arkiston mallia, ovat ohut kerros sovelluskerroksen ja tietojen Käyttöoikeuskerroksen välissä. Ne yleensä hallita CRUD Operations kanssa tietokanta paikallisesti tai etänä.

• näkymässä on käyttäjien kanssa vuorovaikutuksessa olevia vastuita.

  se ei sisällä mitään logiikkaa. Se reitittää käyttäjän syötteitä ja komentoja (tapahtumia) juontajalle.

  näkymässä on yleensä viittaus Juontajaansa.

• juontaja on katseen ja mallin välimuoto. Se on sama rooli kuin ohjain MVC kuvio.

  kaikki bisneslogiikka, datalogiikka, validoi syöte, vastaanottaa tapahtumia näkymistä, muuntaa dataa näkymästä malliin tai mallista toiseen toteutetaan Presenterissä.

  verrattuna MVC-kuvion näkymään ja ohjaimeen, MVP-kuvion näkymä ja juontaja ovat täysin irti toisistaan ja ne kommunikoivat rajapinnan avulla. (Juontaja vuorovaikuttaa näkymien kanssa Näkymäliittymän kautta, se tarkoittaa, että juontaja voi suorittaa kaikki esitystehtävät ja suunnistustehtävät ilman riippuvuutta käytettävästä KÄYTTÖLIITTYMÄTEKNIIKASTA)

  

  ja meillä on MVP-kuvion sekvenssikaavio:

  

br>

kun käyttää

• näytöllämme on bi-directional-flow, se tarkoittaa, että käyttäjän vuorovaikutusten täytyy pyytää jotain malliltamme, ja tämän pyynnön tulos vaikuttaa näkymään.

• näkymä, johon Mallipäivitykset vaikuttavat, on hyvin rajallinen.

• MVP-mallia ei käytetä tapauksessa, jossa käyttöliittymää päivitetään ilman käyttäjän vuorovaikutusta, kuten käyttöliittymän päivittäminen, kun mallissa tapahtuu tapahtuma, tämä lähestymistapa on lähempänä MVVM: ää enemmän kuin MVP.

hyödyt & haittapuolet

1. edut

   • näkymä ei ole suoraan vuorovaikutuksessa Mallin kanssa. Tämä eristää näkymän toteutuksen paremmin kuin MVC: ssä ja mahdollistaa helpommin automatisoidun esittelijän ja mallin yksikkötestauksen.

   • käyttöliittymän vaihtaminen verkosta ikkunaan tai mobiiliin on erittäin helppoa.

   alhaiset ylläpitokustannukset

2. haittapuolet

   • juontajalla on taipumus laajentua valtavaksi kaikkitietäväksi luokaksi, jos emme ole tarpeeksi varovaisia emmekä riko koodiamme yhden vastuun periaatteen mukaisesti.

   • lisääntynyt monimutkaisuus.

   • ylimääräinen oppimiskäyrä.

jotkut MVP – kuvioon liittyvät kuviot

• Application Controller – jos juontajat ovat vuorovaikutuksessa sovellusohjaimen kanssa, juontajat eivät tarvitse sivuvirtausta ja näytön navigointilogiikkaa. Tämä helpottaa sivuvirran päivittämistä.

Observer pattern

kääre

• loppukäyttäjä on vuorovaikutuksessa vain näkymän kanssa.

• yksi näkymä on kartoitettu vain yhdelle juontajalle.

• Katso viitteet juontaja, mutta siinä ei ole mainintaa mallista. Juontaja on myös tietoinen siihen liittyvästä näkemyksestä.

• kuvio mahdollistaa kaksisuuntaisen kommunikaation näkymän ja juontajan välillä.

• MVP-kuviosta on olemassa kaksi muutakin toteutusta, kuten Passive View ja Supervising Controller.

  • passiivinen näkymä on täysin juontajan kontrolloima. Toteuttamalla MVP passiivinen näkymä, se on paljon helpompi käsitellä samanaikaisesti ja monilukua.

  • valvoessaan Presenteriä näkymä on suorassa vuorovaikutuksessa Mallin kanssa suorittaakseen minkä tahansa yksinkertaisen tiedon sitomisen, joka voidaan määritellä deklaratiivisesti, ilman juontajaa. Juontaja päivittää mallia. Se muuttaa näkymän tilaa vain, kun vaaditaan monimutkaista KÄYTTÖLIITTYMÄLOGIIKKAA, jota ei voida määrittää deklaratiivisesti.

    

  • vertaa muihin MVP: n muunnelmiin, kuten Passiivinäkymään, valvova Juontajakuvio tekee yksinkertaisemmasta koodista korkeamman prioriteetin kuin täydellisestä testattavuudesta. Valvova juontaja kuvio vaatii vähemmän koodia kuin muut MVP kuvioita, koska se käyttää tietojen Sitominen. Koodia on helpompi ylläpitää, koska yksinkertaiset KÄYTTÖLIITTYMÄMUUTOKSET eivät vaadi juontajan koodimuutoksia näkymän päivittämiseksi.

:

https://www.linkedin.com/pulse/mvp-architecture-pattern-small-article-khaled-kassem/

Book Architectural Patterns_ Uncover essential patterns in the most indispensable realm of enterprise architecture

https://www.oreilly.com/library/view/architectural-patterns/9781787287495/38abcb95-0392-4127-a3fa-b80ac2807aa9.xhtml

The other idea about Presenter in MVP pattern and Controller in MVC pattern

http://hannesdorfmann.com/mosby/mvp/

Choose MVP pattern over MVC pattern

Why Do You Need to Choose MVP Over MVC Android Architectural Pattern?

Examples for MVP pattern

http://aviadezra.blogspot.com/2008/10/model-view-presenter-design-pattern.html

https://www.raywenderlich.com/7026-getting-started-with-mvp-model-view-presenter-on-android

https://www.linkedin.com/pulse/when-use-mvc-mvp-mvvm-nothing-ahmed-adel/

A Model View Presenter (MVP) implementation with ASP.NET

A brief introduction to a cleaner Android architecture: The MVP pattern

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649571(v=pandp.10)