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.

og MVP-mønster stammer fra begyndelsen af 1990 ‘ erne hos Taligent, et joint venture mellem Apple, IBM og Hevlett-Packard.

nedenfor er indholdet af hver del i MVP mønster.

• modellen har enheder og tjenester.

  enheder bruges til at indeholde data, der er kortlægning med tabel i databasen for at udnytte nogle andre grunde.

  tjenester, kan bruges DAO mønster, eller Repository mønster, er tyndt lag mellem ansøgning lag og Data adgang lag. De administrerer normalt CRUD-operationer med database i lokal eller fjern.

• Visningen har ansvar, der interagerer med brugerne.

  det indeholder ingen logik. Det vil dirigere brugerindgange og kommandoer (begivenheder) til præsentanten.

  Visningen har normalt en henvisning til dens præsentator.

• præsentationsværten er den mellemliggende del mellem visning og Model. Det vil spille samme rolle som Controller i MVC mønster.

  alle forretningslogik, Datalogik, validere input, modtager begivenheder fra Visninger, konverterer data fra visning til Model eller fra Model til visning implementeres i præsentator.

  sammenlignet med visningen og controlleren i MVC-mønsteret, er visningen og præsentanten, der er til stede i MVP-mønsteret, helt afkoblet fra hinanden, og de kommunikerer ved hjælp af en grænseflade. (Præsentanten interagerer med visningerne via visningsgrænsefladen, det betyder, at præsentanten kan udføre alle præsentations-og navigationsopgaver uden nogen afhængighed af den faktiske UI-teknologi, der bruges)

  

  og vi har sekvensdiagram over MVP-mønster:

  

hvornår skal du bruge

• vores skærm har bi-directional-flow, det betyder, at brugerinteraktioner skal anmode om noget fra vores model, og resultatet af denne anmodning vil påvirke visningen.

• visningen påvirket af opdateringerne fra Model er meget begrænset.

• MVP-mønster bruges ikke i et tilfælde, hvor brugergrænsefladen opdateres uden brugerinteraktioner, som at opdatere brugergrænsefladen, når en begivenhed sker i modellen, er denne tilgang tættere på MVVM mere end MVP.

fordele& ulempe

1. fordele

   • visningen interagerer ikke direkte med Modellen. Dette isolerer visningen implementering bettern end i MVC og giver lettere automatiseret enhed test af studievært og Model.

   • evnen til at ændre brugergrænsefladen fra Internet til vindue eller mobil er meget let.

   • lave vedligeholdelsesomkostninger

2. ulemper

   • præsentanten har en tendens til at udvide til en enorm alvidende klasse, hvis vi ikke er forsigtige nok og ikke bryder vores kode i henhold til princippet om et enkelt ansvar.

   • øget kompleksitet.

   • ekstra indlæringskurve.

nogle mønstre, der er relevante for MVP – mønster

• Application Controller – hvis præsentanter interagerer med en applikationscontroller, har præsentanterne ikke brug for sidestrøm og skærmnavigationslogik. Dette gør det lettere at opdatere sidestrømmen.

• Observer pattern

indpakning

• slutbrugeren interagerer kun med visningen.

• en visning er kun kortlagt til en præsentator.

• se referencer studievært, men det har ingen henvisning til Model. Og præsentanten er også opmærksom på det synspunkt, der er forbundet med det.

• mønsteret faciliterer tovejskommunikation mellem visningen og præsentanten.

• der er to andre implementeringer af MVP mønster såsom passiv visning og tilsynsførende Controller.

  • den Passive visning styres fuldstændigt af præsentator. Ved at implementere MVP passiv visning er det meget lettere at håndtere samtidighed og multithreading.

  • i Supervising Presenter interagerer visningen direkte med modellen for at udføre enhver simpel databinding, der kan defineres deklarativt uden præsentanten. Præsentanten opdaterer modellen. Det ændrer kun visningens tilstand, når kompleks UI-logik, der ikke kan angives deklarativt, er påkrævet.

    

  • Sammenlign med andre variationer af MVP, såsom passiv visning, gør det tilsynsførende Præsentationsmønster enklere kode til en højere prioritet end fuldstændig testbarhed. Det tilsynsførende Præsentationsmønster kræver mindre kode end andre MVP-mønstre, fordi det bruger databinding. Koden er lettere at vedligeholde, fordi enkle UI-ændringer ikke kræver kodeændringer i præsentationsværten for at opdatere visningen.

henvis:

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)