i denne artikkelen vil vi finne noe ut OM MVP mønster, det er arvet FRA MVC mønster. Men definitivt, det har noen endringer i forhold TIL MVC mønster. Så, vi vil forstå hvordan du bruker det, hvordan du skiller MELLOM MVC mønster og MVP mønster.

La oss komme i gang.

Analyse Problem

forsiktigheten som ble født MVP mønsteret er det samme som med mvc mønster. Men MVP brukes til å hindre noen ulemper MED MVC mønster som:

• I MVC mønster, Utsikt og Modell kan samhandle hverandre. Så, vi validerer vanligvis data Fra Modell eller bruker datalogikk I Sikte. Så, det gjør automatisert enhetstesting vanskelig.
• det er relevant for sikkerheten.

Definisjon AV Mvvm Mønster

I Henhold til wikipedia.com, har vi definisjonen AV mvp mønster:

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 oppsto tidlig på 1990-tallet På Taligent, Et joint venture Av Apple, IBM og Hewlett-Packard.

Nedenfor er innholdet i hver del I MVP mønster.

• Modellen har enheter og tjenester.

  Enheter brukes til å inneholde data som er kartlegging med tabell i databasen for å utnytte noen andre grunner.Tjenester, KAN brukes DAO mønster, Eller Depotet mønster, er tynt lag Mellom Applikasjonslaget og Datatilgangslaget. De normalt administrere CRUD operasjoner med database i lokal eller ekstern.

• Visningen har ansvar som samhandler med brukere.

  det inneholder ingen logikk. Det vil rute brukerinnganger og kommandoer (hendelser) Til Presentatøren.

  Visningen har vanligvis en referanse til Presentatøren.Presentatøren er den mellomliggende delen mellom Visning og Modell. Det vil spille samme rolle Som Kontrolleren I MVC mønster.All forretningslogikk, datalogikk, validering av inndata, mottar hendelser fra Visninger, konverterer data Fra Visning Til Modell eller Fra Modell Til Visning, implementeres i Presenter.

  sammenlignet Med Visningen og Kontrolleren I MVC-mønsteret, Er Visningen og Presentatøren som er tilstede i MVP-mønsteret, fullstendig koblet fra hverandre og de kommuniserer ved hjelp av et grensesnitt. (Presentatøren samhandler med Visningene via Visningsgrensesnitt, det betyr At Presentatøren kan utføre alle presentasjons-og navigasjonsoppgaver uten avhengighet av den faktiske UI-teknologien som brukes)

  

  

når du skal bruke

• skjermen VÅR HAR bi-directional-flow, betyr det at brukerinteraksjoner må be om noe fra vår modell, og resultatet av denne forespørselen vil påvirke visningen.

• Visningen påvirket av oppdateringer Fra Modellen er svært begrenset.

• MVP-mønster brukes ikke i et tilfelle NÅR BRUKERGRENSESNITTET oppdateres uten brukerinteraksjoner, som å oppdatere BRUKERGRENSESNITTET når en hendelse skjer i Modellen, er denne tilnærmingen nærmere MVVM mer enn MVP.

Fordeler & Ulempe

1. Fordeler

   • Visningen samhandler ikke direkte med Modellen. Dette isolerer Visningsimplementeringen bedre enn I MVC og tillater enklere automatisert enhetstesting av Presentatøren og Modellen.

   • muligheten til å endre BRUKERGRENSESNITTET Fra Web Til Vindu eller Mobil er veldig enkelt.Lav vedlikeholdskostnad

2. Ulemper

   • Presentatøren har en tendens til å utvide til en stor allvitende klasse hvis vi ikke er forsiktige nok og ikke bryter koden vår I Henhold til Enkeltansvarsprinsipp.

   • Økt kompleksitet.

   • Ekstra læringskurve.

noen mønstre som er relevante FOR MVP mønster

• Application Controller – hvis presentatørene samhandler med en programkontroller, trenger ikke presentatørene sideflyt og skjermnavigasjonslogikk. Dette gjør det enklere å oppdatere sideflyten.

• Observer pattern

Innpakning

• sluttbrukeren samhandler bare Med Visningen.

• En Visning er bare tilordnet En Presentatør.

• Vis Referanser Presentatør, men Det har ingen referanse Til Modell. Og Presentatøren er også klar over Visningen som er knyttet til den.

• mønsteret omfatter toveis kommunikasjon mellom Visningen og Presentatøren.

• Det er to andre implementeringer AV MVP mønster som Passiv Visning og Tilsyn Kontrolleren.

  • Den Passive Visningen styres helt av Presentatør. Ved å implementere Mvp Passiv Visning, er det mye lettere å håndtere samtidighet og multithreading.

  • I Tilsyn Presenter, Visningen samhandler direkte Med Modellen til å utføre noen enkel data binding som kan deklarativt definert, uten Presentatør. Presentatøren oppdaterer Modellen. Det endrer bare Tilstanden Til Visningen når kompleks UI-logikk som ikke kan angis deklarativt kreves.

    

  • Sammenlign med andre varianter AV MVP, For Eksempel Passiv Visning, Gjør Overvåkingspresentasjonsmønsteret enklere kode høyere prioritet enn fullstendig testbarhet. Tilsyn Presentatør mønsteret krever mindre kode enn andre mvp mønstre fordi den bruker data binding. Koden er enklere å vedlikeholde fordi enkle ENDRINGER I BRUKERGRENSESNITTET ikke krever kodeendringer i Presentatøren for å oppdatere Visningen.

Se:

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)