Hva er MVP og MVC og hva er forskjellen?

stemmer
1k

Når du ser utover RAD (dra-slipp og konfigurere) måte å bygge brukergrensesnitt som mange verktøy oppmuntrer du er sannsynlig å komme over tre design mønstre kalt Model-View-Controller , Model-View-Presenter og Model-View-ViewModel . Mitt spørsmål har tre deler til det:

  1. Hvilke saker trenger adressere disse mønstrene?
  2. Hvordan er de like?
  3. Hvordan er de forskjellige?
Publisert på 05/08/2008 klokken 10:06
kilden bruker
På andre språk...                            


25 svar

stemmer
1k

Model-View-Presenter

I MVP inneholder Presenter UI forretningslogikk for visningen. Alle besvergelser fra Vis delegat direkte til programleder. Presenter er også dekoblet direkte fra Se og snakker til den gjennom et grensesnitt. Dette er for å tillate tentamen av visningen i en enhet test. En vanlig egenskap av MVP er at det må være mye toveis forsendelse. For eksempel når noen klikker på "Lagre" -knappen, hendelsesbehandling delegater til presentatørens "OnSave" metoden. Når lagringen er fullført, vil Presenter deretter ringe tilbake utsikten gjennom sitt grensesnitt, slik at visningen kan vise at lagringen er fullført.

MVP har en tendens til å være en veldig naturlig mønster for å oppnå skilt presentasjon i Web Forms. Årsaken er at utsikten er alltid skapt først av ASP.NET runtime. Du kan finne ut mer om begge variantene .

To primære variasjoner

Passiv View: The View er så dum som mulig og inneholder nesten null logikk. Den Presenter er en middelaldrende mann som snakker til Vis og modell. The View og modell er helt skjermet fra hverandre. Modellen kan øke hendelser, men Presenter abonnerer på dem for å oppdatere visningen. I Passiv Vis det er ingen direkte data bindende, i stedet Se eksponerer setter-egenskaper som Presenter bruker for å sette dataene. All statlig forvaltes i Presenter og ikke utsikten.

  • Pro: maksimal testbarhet overflaten; ren separasjon av Se og modell
  • Con: mer arbeid (for eksempel alle de setter-egenskaper) som du gjør alle data bindende selv.

Tilsyn Controller: Den Presenter håndterer bruker bevegelser. The View binder seg til Model direkte gjennom databinding. I dette tilfellet er det Presenter jobb å passere av Model til Vis slik at det kan binde seg til det. Presenter vil også inneholde logikk for bevegelser som å trykke på en knapp, navigasjon, etc.

  • Pro: ved å utnytte databinding mengden med kode er redusert.
  • Con: det er mindre testbar overflaten (på grunn av databinding), og det er mindre innkapsling i Vis siden den snakker direkte til modell.

Model-View-Controller

I MVC , er kontrolleren ansvarlig for å bestemme hvilke View for å vise svar på eventuelle tiltak også når programmet laster. Dette skiller seg fra MVP der handlinger ruten gjennom Utsikt mot Presenter. I MVC, hver handling i Vis korrelerer med en oppfordring til en Controller sammen med en handling. I web hver handling innebærer en samtale til en nettadresse på den andre siden av der det er en Controller som svarer. Når det Controller har fullført sin behandling, vil den returnere riktig View. Sekvensen fortsetter på denne måte gjennom hele livet av søknaden:

    Handling i Vis
        -> Ring til Controller
        -> Controller Logic
        -> Controller returnerer View.

En annen stor forskjell om MVC er at utsikten ikke direkte binder til modell. Utsikten bare gjør, og er helt statsløs. I implementeringer av MVC Vis vanligvis ikke vil ha noen logikk i koden bak. Dette er i strid med MVP der det er absolutt nødvendig, fordi hvis Vis ikke delegere til Presenter, det vil aldri bli kalt.

presentasjon Model

En annen mønster å se på er den Presentasjon Model mønster. I dette mønsteret er det ingen Presenter. I stedet Se binder direkte til en presentasjon Model. Presentasjonen modell er en modell laget spesielt for visning. Dette betyr at denne modell kan utsette egenskaper som man aldri ville sette på et domene modell som det ville være i strid med atskillelse-of-bekymringer. I dette tilfellet, binder Presentasjon Model til domenemodellen, og kan abonnere på hendelser som kommer fra denne modellen. The View deretter abonnerer på hendelser som kommer fra Presentasjon Model og oppdaterer seg selv deretter. Presentasjonen Model kan utsette kommandoer som utsikten bruker for å påkalle handlinger. Fordelen med denne tilnærmingen er at du egentlig kan fjerne kode bak helt som PM helt omslutter all atferd for visningen. Dette mønsteret er en meget sterk kandidat til bruk i WPF applikasjoner og kalles også Model-View-ViewModel .

Det er en MSDN artikkel om presentasjonsform og en seksjon i Composite Application Guidance for WPF (former Prism) om Separerte Presentasjons Patterns

Svarte 19/09/2008 kl. 12:46
kilden bruker

stemmer
384

Jeg blogget om dette en stund tilbake, siterer på Todd Snyders utmerket innlegg på forskjellen mellom de to :

Her er de viktigste forskjellene mellom mønstrene:

MVP Pattern

  • Vis er mer løst koplet til modellen. Programleder er ansvarlig for binding modellen til visningen.
  • Lettere å enhet test fordi vekselvirkning med visningen er gjennom et grensesnitt
  • Vanligvis vise til programleder kartet 12:59. Komplekse utsikt kan ha flere foredragsholdere.

MVC Pattern

  • Controller er basert på atferd og kan deles på tvers visninger
  • Kan være ansvarlig for å avgjøre hvilken visning som skal vises

Det er den beste forklaringen på nettet jeg kunne finne.

Svarte 05/08/2008 kl. 10:21
kilden bruker

stemmer
371

Dette er en overforenkling av de mange varianter av disse design mønstre, men dette er slik jeg liker å tenke på forskjellene mellom de to.

MVC

MVC

MVP

skriv bildebeskrivelse her

Svarte 06/07/2013 kl. 22:18
kilden bruker

stemmer
211

Her er illustrasjoner som representerer kommunikasjonsflyt

skriv bildebeskrivelse her

skriv bildebeskrivelse her

Svarte 12/09/2014 kl. 20:47
kilden bruker

stemmer
149

MVP er ikke nødvendigvis et scenario hvor utsikten er ansvarlig (se Taligent MVP for eksempel).
Jeg synes det er uheldig at folk fortsatt å forkynne dette som et mønster (Vis ansvarlig) i motsetning til en anti-mønster som det motsier "Det er bare et syn" (Pragmatic Programmer). "Det er bare et syn" sier at det siste bildet vises for brukeren er en sekundær bekymring for søknaden. Microsofts MVP mønster gjør gjenbruk av Visninger mye vanskeligere og mer bekvemt unnskyldninger Microsofts designer fra oppmuntrende dårlig praksis.

For å være helt ærlig, tror jeg de underliggende bekymringene til MVC gjelder for alle MVP gjennomføring og forskjellene er nesten utelukkende semantisk. Så lenge man følger atskillelse av bekymringer mellom visningen (som viser dataene), styreenheten (som initialiserer og kontrollerer brukerens interaksjon) og modellen (de underliggende data og / eller tjenester)) da du acheiving fordelene av MVC . Hvis du acheiving fordelene deretter som virkelig bryr seg om mønsteret er MVC, MVP eller tilsyn Controller? Den eneste virkelige mønsteret fortsatt som MVC, resten er bare forskjellige varianter av det.

Vurdere dette svært spennende artikkel som omfattende lister opp en rekke av disse ulike implementeringer. Du kan merke at de er alle i utgangspunktet gjøre det samme, men litt annerledes.

Jeg tror personlig MVP har bare nylig blitt re-introdusert som en fengende begrep for å enten redusere argumenter mellom semantiske trangsynte som hevder om noe er virkelig MVC eller ikke, eller å rettferdig Microsofts Rapid Application Development verktøy. Ingen av disse grunnene i bøkene mine rettferdiggjøre sin eksistens som et eget design mønster.

Svarte 25/08/2008 kl. 21:22
kilden bruker

stemmer
90

MVP: visningen er ansvarlig.

Utsikten, i de fleste tilfeller, skaper sitt programleder. Presentatøren skal samhandle med modellen og manipulere utsikten gjennom et grensesnitt. Utsikten vil noen ganger samhandle med programleder, vanligvis gjennom noen grensesnitt. Dette kommer ned til gjennomføring; ønsker du utsikten kalle metoder på den som presenterer eller ønsker du utsikten til å ha arrangementer programleder lytter til? Det koker ned til dette: Utsikten vet om den som presenterer. Visningen delegater til den som presenterer.

MVC: kontrolleren er ansvarlig.

Kontrolleren er opprettet eller åpnes basert på noen hendelse / forespørsel. Kontrolleren oppretter deretter et passende utsnitt og virker sammen med modellen for ytterligere å konfigurere visningen. Det koker ned til: kontrolleren lager og styrer visningen; visningen er slave til kontrolleren. Utsikten vet ikke om kontrolleren.

Svarte 06/08/2008 kl. 22:51
kilden bruker

stemmer
62

skriv bildebeskrivelse her

MVC (Model View Controller)

Inngangen er rettet mot den første kontrolleren, ikke utsikten. At innspill kan komme fra en bruker i samspill med en side, men det kan også være fra å skrive inn en bestemt url i en nettleser. I begge tilfeller, dens en Controller som er integrert med kick off noe funksjonalitet. Det er en mange-til-en forhold mellom Controller og visning. Det er fordi en enkelt kontroller kan velge forskjellige visninger for å bli gjengitt på grunnlag av den operasjon som blir utført. Legg merke til en vei pilen fra Controller for å se. Dette er fordi Vis ikke har noen kunnskap om eller henvisning til kontrolleren. Kontrolleren gjør pass tilbake modell, så det er kunnskap mellom Se og forventet modell som sendes inn i det, men ikke Controller tjene det opp.

MVP (Model View Presenter)

Inngangen begynner med visningen, ikke Presenter. Det er en en-til-en mapping mellom Se og tilhørende Presenter. The View har en referanse til den som presenterer. Presenter er også reagere på hendelser som blir utløst fra View, så det er klar over Se sin assosiert med. Presenter oppdaterer Vis basert på de forespurte handlinger den utfører på Model, men utsikten er ikke modell klar.

For mer Reference

Svarte 20/12/2015 kl. 02:10
kilden bruker

stemmer
31

Også verdt å huske er at det er forskjellige typer MVPer også. Fowler har brutt mønsteret i to - Passiv Se og tilsyn Controller.

Ved bruk av passiv View, din Se vanligvis gjennomføre en finkornet grensesnitt med egenskaper kartlegging mer eller mindre direkte til underliggende UI widget. For eksempel kan du ha en ICustomerView med egenskaper som navn og adresse.

implementeringen kan se omtrent slik ut:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Din Presenter klassen vil snakke til modellen og "kart" det til visningen. Denne tilnærmingen kalles "passiv View". Fordelen er at utsikten er enkelt å teste, og det er lettere å bevege seg mellom UI plattformer (web, Windows / XAML, etc.). Ulempen er at du ikke kan utnytte ting som databinding (som er virkelig kraftig i rammeverk som WPF og Silverlight ).

Den andre smaken av MVP er overvåknings Controller. I så tilfelle Vis kan ha en egenskap kalt Kunden, som så igjen er databound til UI widgets. Du trenger ikke å tenke på synkronisering og detaljstyre visningen, og tilsyn Controller kan gå inn og hjelpe når det trengs, for eksempel med compled samhandling logikk.

Den tredje "smaken" av MVP (eller noen ville kanskje kalle det et eget mønster) er den Presentasjon Model (eller noen ganger referert til Model-View-ViewModel). Sammenlignet med MVP deg "flette" M og P i en klasse. Du har din kunde objekt som for brukergrensesnittet widgets er data bundet til, men du har også flere UI-spesifikk felt som "IsButtonEnabled", eller "IsReadOnly", osv

Jeg tror den beste kilden jeg har funnet å UI arkitektur er rekke blogginnlegg gjort av Jeremy Miller over på Build Your Own CAB-serien Fortegnelse . Han dekket alle smakene av MVP og viste C # -kode for å implementere dem.

Jeg har også blogget om Model-View-ViewModel mønster i sammenheng med Silverlight over på YouCard Re-besøkt: Implementere ViewModel mønster .

Svarte 08/08/2008 kl. 05:55
kilden bruker

stemmer
31
  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Begge presentasjonsmønstre. De skille avhengigheter mellom en modell (tror Domain gjenstander), skjermen / web-side (Vis), og hvordan UI er ment å oppføre seg (Presenter / Controller)
    2. De er ganske like i konsept, folkens initialisere Presenter / Controller forskjellig avhengig av smak.
    3. En flott artikkel om forskjellene er her . Mest bemerkelsesverdig er at MVC mønsteret har Model oppdatere View.
Svarte 05/08/2008 kl. 10:22
kilden bruker

stemmer
18

Det er mange svar på det spørsmålet, men jeg følte det er behov for noen virkelig enkle svaret klart å sammenligne de to. Her er diskusjonen jeg gjort opp når en bruker søker etter en film navn i en MVP og MVC app:

Bruker: Klikk klikk ...

Vis : Hvem er det? [ MVP | MVC ]

Bruker: Jeg klikket på søkeknappen ...

Vis : Ok, vent et øyeblikk .... [ MVP | MVC ]

( Vis ringe Presenter | Controller ...) [ MVP | MVC ]

Vis : Hey Presenter | Controller , har en bruker bare klikket på søkeknappen, hva skal jeg gjøre? [ MVP | MVC ]

Presenter | Controller : Hey Se , er det noen søkeord på siden? [ MVP | MVC ]

Vis : Ja, ... her er det ... “piano” [ MVP | MVC ]

Programleder : Thanks Se ... imens jeg ser opp søkeordet på Model , kan du vise ham / henne en fremdriftslinje [ MVP | MVC ]

( Presenter | Controller kaller den Model ...) [ MVP | MVC ]

Presenter | Controller : Hey modell , Har du noen match for dette søkeordet ?: “piano” [ MVP | MVC ]

Modell : Hey Presenter | Controller , la meg sjekke ... [ MVP | MVC ]

( Modell er å lage en spørring til filmen database ...) [ MVP | MVC ]

( Etter en stund ... )

-------------- Det er der MVP og MVC begynner å divergere ---------------

Modell : Jeg fant en liste for deg, Presenter , her er det i JSON “[{ "name": "Pianolærerinnen", "år": 2001}, { "name": "Piano", "år": 1993} ]”[ MVP ]

Modell : Det er noe resultat tilgjengelig, Controller . Jeg har laget et felt variabel i mitt tilfelle, og fylte den med resultatet. Det navnet er "searchResultsList" [ MVC ]

( Presenter | Controller takket modell og kommer tilbake til Vis ) [ MVP | MVC ]

Programleder : Takk for venter Se , jeg fant en liste over samsvarende resultater for deg og ordnet dem i en presentabel format: [ "Pianolærerinnen 2001", "Piano 1993"]. Vennligst vise den til brukeren i en vertikal liste. Også kan du skjule fremdriftslinjen nå [ MVP ]

Controller : Takk for venter Se , jeg har spurt Modell om søket. Det står at den har funnet en liste over samsvarende resultater og lagret dem i en variabel som heter "searchResultsList" inni sitt eksempel. Du kan få det derfra. Også kan du skjule fremdriftslinjen nå [ MVC ]

Vis : Tusen takk Presenter [ MVP ]

Vis : Takk "Controller" [ MVC ] (Nå visningen er avhør selv: Hvordan skal jeg presentere resultatene jeg får fra Model ? Til brukeren Skulle produksjonsår av filmen kommer først eller sist ... Bør det? være i en vertikal eller horisontal liste? ...)

I tilfelle du er interessert, jeg har skrevet en rekke artikler som omhandler app arkitektoniske mønstre (MVC, MVP, MVVP, ren arkitektur, ...) ledsaget av en Github repo her . Selv om utvalget er skrevet for android, kan de underliggende prinsippene brukes på ethvert medium.

Svarte 06/04/2018 kl. 13:51
kilden bruker

stemmer
16

Begge disse rammer har som mål å skille bekymringer - for eksempel samvirke med en datakilde (modell), applikasjonslogikk (eller vrir disse dataene til nyttig informasjon) (Controller / Presenter) og viser kode (View). I noen tilfeller modellen kan også benyttes til å slå en datakilde til et høyere nivå abstraksjon i tillegg. Et godt eksempel på dette er MVC Storefront prosjektet .

Det er en diskusjon her om forskjellene mellom MVC vs MVP.

Distinksjonen er at i en MVC søknad som tradisjonelt har visningen og styreenheten kommuniserer med modellen, men ikke med hverandre.

MVP design har Presenter tilgang til modellen og samhandle med visningen.

Når det er sagt, ASP.NET MVC er ved disse definisjonene en MVP rammeverk fordi Controller tilgang til modell for å fylle visningen som er ment å ha ingen logikk (bare viser variabler levert av kontrolleren).

Å kanskje få et inntrykk av ASP.NET MVC forskjell fra MVP, sjekk ut denne MIX presentasjonen av Scott Hanselman.

Svarte 05/08/2008 kl. 10:20
kilden bruker

stemmer
14

De hver tar for seg ulike problemstillinger og kan også kombineres sammen for å ha noe sånt under

Den kombinerte mønster

Det er også en fullstendig sammenligning av MVC, MVP og MVVM her

Svarte 13/03/2017 kl. 05:54
kilden bruker

stemmer
12

Begge er mønstre prøver å skille presentasjon og forretningslogikk, decoupling forretningslogikk fra UI aspekter

Arkitektonisk er MVP Page Controller basert tilnærming der MVC er Front Controller basert tilnærming. Det betyr at i MVP standard webskjema side livssyklus er bare forsterkes av utpakking av forretningslogikk fra koden bak. Med andre ord, siden er det en service http forespørsel. Med andre ord, er MVP IMHO webskjema evolusjonære type ekstrautstyr. MVC på annen side endrer fullstendig spillet fordi forespørselen blir mottatt av kontrolleren klassen før siden er lastet, forretningslogikken er utført der og da på sluttresultatet av kontrolleren bearbeiding av data bare dumpet til siden ( "view") i den forstand, MVC utseende (minst for meg) mye å Tilsyn Controller smaken av MVP forbedret med ruting motor

Begge aktiver TDD og har ulemper og oppsider.

Beslutning om hvordan du velger en av dem IMHO bør være basert på hvor mye tid man investert i ASP NET webskjema type webutvikling. Hvis man ville vurdere seg godt i webskjemaer, vil jeg foreslå MVP. Hvis man ville føle seg ikke så behagelig i ting som siden livssyklus etc MVC kan være en vei å gå her.

Her er enda et blogginnlegg lenke gi litt mer informasjon om dette emnet

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Svarte 21/09/2008 kl. 12:32
kilden bruker

stemmer
10

Model-View-Controller

MVC er et mønster for arkitekturen i et program. Det skille applikasjonslogikken i tre adskilte deler, fremme modularitet og lette samarbeid og gjenbruk. Det gjør også anvendelser mer fleksibel og innbydende til iterations.It skiller en applikasjon i de følgende komponenter:

  • Modeller for håndtering av data og forretningslogikk
  • Controllers for håndtering av brukergrensesnittet og søknad
  • Visninger for håndtering av grafiske brukergrensesnitt gjenstander og presentasjon

For å gjøre dette litt mer klart, la oss tenke oss en enkel handleliste app. Alt vi ønsker er en liste over navn, antall og pris på hvert element vi trenger å kjøpe denne uken. Nedenfor vil vi beskrive hvordan vi kan gjennomføre noen av denne funksjonaliteten bruke MVC.

skriv bildebeskrivelse her

Model-View-Presenter

  • Den modellen er de data som vil bli vist i visningen (brukergrensesnitt).
  • Den syn er et grensesnitt som viser data (modellen), og ruter brukerkommandoer (hendelser) til Presenter til å virke på disse dataene. Visningen har vanligvis en referanse til sin Presenter.
  • Den Presenter er “midt-man” (spilt av styreenheten i MVC), og har referanser til begge, visning og modell. Vær oppmerksom på at ordet “modell” er misvisende. Det bør heller være forretningslogikk som henter eller manipulerer en modell . For eksempel: Hvis du har en database lagring Bruker i en database tabell og din Se ønsker å vise en liste over brukere, så Presenter ville ha en referanse til databasen forretningslogikk (som en DAO) fra der Presenter vil spørre en liste brukere.

Hvis du vil se et eksempel med enkel implementering kan du sjekke dette github post

Et konkret arbeidsflyten av spørring og vise en liste over brukere fra en database kan fungere som dette: skriv bildebeskrivelse her

Hva er forskjellen mellom MVC og MVP mønstre?

MVC Pattern

  • Controller er basert på atferd og kan deles på tvers visninger

  • Kan være ansvarlig for å avgjøre hvilken visning til visning (Front Controller Mønster)

MVP Pattern

  • Vis er mer løst koplet til modellen. Programleder er ansvarlig for binding modellen til visningen.

  • Lettere å enhet test fordi vekselvirkning med visningen er gjennom et grensesnitt

  • Vanligvis vise til programleder kartet 12:59. Komplekse utsikt kan ha flere foredragsholdere.

Svarte 29/11/2017 kl. 10:14
kilden bruker

stemmer
9

I android er det versjon av MVC som er MVP: Hva er MVP?

MVP mønsteret gjør skille presentasjonen laget fra logikken, slik at alt om hvordan grensesnittet fungerer er adskilt fra hvordan vi representerer det på skjermen. Ideelt MVP mønster ville oppnå det samme logikken kan ha helt forskjellige og utskiftbare visninger.

Første ting å avklare er at MVP er ikke en arkitektonisk mønster, det er bare ansvarlig for presentasjonen laget. I alle fall er det alltid bedre å bruke den for arkitektur som ikke bruker det i det hele tatt.

Et eksempel for MVP er https://github.com/antoniolg/androidmvp

Hva er MVC? MVC-arkitektur er en av de eldste mønstre tilgjengelig for å oppnå separasjon av bekymringer. MVC består av tre lag, nemlig, Modell, Vis og kontroller.

Classic MVC eksistert i en tid da hver kontroll / gadget som fantes i skjermen ble ansett dum og hver kontroll er sammenkoblet med sin egen kontroller for å administrere brukerinteraksjoner skjer på dem. Så hvis 10 gadgets finnes, så 10-kontrollere har å eksistere. I dette scenariet, hver gadget telles som en visning. Ankomsten av Windows grafiske systemer endret dette bildet. Kontroll-Controller forholdet ble foreldet. Styrer fikk intelligens til å svare på de handlinger initiert av brukeren. I Windows verden, er utsikten en overflate som alle Kontroll / gadgets finnes, dermed er det et behov for bare én kontroller. Utsikten kan motta hendelser og nå for kontrollerne bidra til å gjøre videre behandling.

Eksempelkode for MVC i android http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

Forskjellen mellom begge er tilgjengelig her http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Nå Fra min erfaring må du bruke MVP for android basert prosjekt, fordi det forbedret versjon av MVC modell.

Svarte 02/07/2016 kl. 07:15
kilden bruker

stemmer
9

Noe jeg ikke får er hvorfor databinding har for å redusere testbarhet. Jeg mener, en utsikt effektivt basert ut av hva som kan betraktes som en eller flere visninger database, ikke sant? Det kan være sammenhenger mellom rader i forskjellige visninger. Alternativt kan vi snakke objektorientert i stedet for relasjons, men som faktisk ikke endre noe - vi har fortsatt en eller flere distinkte data enheter.

Hvis vi ser programmering som datastrukturer + algoritmer, så ville det være best å ha datastrukturer gjort eksplisitt som mulig, og deretter utvikle algoritmer som hver er avhengige av så lite stykke data som mulig, med minimal kobling mellom algoritmer ?

Jeg føler veldig Java-esque FactoryFactoryFactory tankemønstre her - vi ønsker å ha flere visninger, flere modeller, flere frihetsgrader over alt. Det er nesten sånn er drivkraften bak MVC og MVP og whatnot. Nå la meg stille dette: hvor ofte er prisen du betaler for dette (og det mest definitivt er en kostnad) verdt det?

Jeg ser heller ingen diskusjon om hvordan du effektivt håndtere tilstand mellom HTTP-forespørsler. Har vi ikke lært fra de funksjonelle folk (og omfangsrik feil gjort av tving spaghetti) som staten er onde og bør minimeres (og når de brukes, bør være godt forstått)?

Jeg ser mye av bruken av begrepene MVC og MVP uten mye bevis for at folk tenke kritisk om dem. Åpenbart er problemet "dem", meg, eller begge deler ...

Svarte 28/01/2009 kl. 21:11
kilden bruker

stemmer
8

Jeg har brukt både MVP og MVC og selv om vi som utviklere tendens til å fokusere på de tekniske forskjellene i begge mønstre poenget for MVP i IMHO er mye mer knyttet til lette adopsjon enn noe annet.

Hvis jeg jobber i et team som allerede som en god bakgrunn på nettet danner utvikling stil det er langt lettere å introdusere MVP enn MVC. Jeg vil si at MVP i dette scenariet er en rask seier.

Min erfaring sier meg at å flytte et lag fra webskjemaer til MVP og deretter fra MVP til MVC er relativt enkelt; beveger seg fra nettformer til MVC er vanskeligere.

Jeg forlater her en link til en serie artikler en venn av meg har publisert om MVP og MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

Svarte 02/01/2009 kl. 10:35
kilden bruker

stemmer
7

I MVP utsikten trekker data fra den som presenterer som trekker og forbereder / normaliserer data fra modellen, mens i MVC regulatoren trekker dataene fra modellen og satt, ved trykk i visningen.

I MVP kan du ha en enkelt visning arbeider med flere typer foredragsholdere og et enkelt programleder arbeide med ulike flere visninger.

MVP bruker vanligvis en slags bindende rammeverk, for eksempel Microsoft WPF bindende rammeverk eller ulike forpliktende rammeverk for HTML5 og Java.

I disse rammene, er det UI / HTML5 / XAML, klar over hva eiendommen av programleder hver UI element skjermer, så når du binder sikte på en programleder, ser utsikten for eiendommene, og vet hvordan å trekke data fra dem og hvordan å sette dem når en verdi endres i brukergrensesnittet av brukeren.

Så hvis for eksempel, er en bil modellen, da programleder er en slags bil programleder, utsetter bilen egenskaper (år, maker, seter, osv) til visningen. Utsikten vet at tekstfeltet kalt 'bil maker' må vise programleder Maker eiendom.

Du kan deretter binde til visningen mange forskjellige typer programleder, alle må ha Maker egenskapen - det kan være et fly, tog eller hva noensinne, ikke utsikten seg ikke. Utsikten trekker data fra programleder - uansett hvor - så lenge den implementerer en avtalt grensesnitt.

Dette bindende rammeverk, hvis du stripe det ned, det er faktisk kontrolleren :-)

Og så kan du se på MVP som en videreutvikling av MVC.

MVC er flott, men problemet er at vanligvis kontrolleren per visning. Controller En vet å sette felt av Vis A. Hvis nå, vil du viser en å vise data fra modell B, må du Controller En kjent modell B, eller du trenger Controller A til å motta et objekt med et grensesnitt - som er like MVP bare uten bindinger, eller du må skrive om UI sett koden Controller B.

Konklusjon - MVP og MVC er både Frakoble av UI mønstre, men MVP bruker vanligvis en bindinger rammeverk som er MVC under. SÅ MVP er på et høyere nivå enn arkitektonisk MVC og et omslag mønster ovenfor av MVC.

Svarte 07/06/2013 kl. 21:16
kilden bruker

stemmer
6

Min ydmyke kort view: MVP er for stor skala, og MVC for små skalaer. Med MVC, jeg en gang føler V og C kan det ses en to sider av en enkelt komponent udelelig heller direkte bundet til M, og en uunngåelig faller til dette når det går ned til kortere skalaer, som UI kontroller og base widgeter. På dette detaljnivået, gjør MVP lite fornuftig. Når man på det motsatte gå til større skalaer, blir riktig grensesnitt enda viktigere, samme med entydige ansvarsforhold, og her kommer MVP.

På den annen side, denne skalaen regel en tommel, kan veie svært lite når plattformegenskaper favoriserer noen form for relasjoner mellom komponentene, som med nettet, hvor det synes å være lettere å implementere MVC, mer enn MVP.

Svarte 20/02/2013 kl. 16:55
kilden bruker

stemmer
4

Det finnes mange versjoner av MVC, dette svaret er om den opprinnelige MVC i Smalltalk. I korte trekk er det bilde av MVC vs MVP

Denne talen droidcon NYC 2017 - Clean app design med Arkitektur Components klargjør det

skriv bildebeskrivelse her skriv bildebeskrivelse her

Svarte 09/09/2015 kl. 02:34
kilden bruker

stemmer
1

Det er denne fine videoen fra onkel Bob, der han kort forklarer MVC og MVP på slutten.

IMO, er MVP en forbedret versjon av MVC hvor du i utgangspunktet skille bekymring for hva du skal vise (data) fra hvordan du skal vise (utsikten). Presenter inkluderer ganske forretningslogikk av UI, implisitt pålegger hva dataene skal presenteres, og gir deg en liste over dumme vise modeller. Og når tiden kommer for å vise dataene, du bare plugge ditt syn (sannsynligvis inneholder de samme id) i adapteren og sette den aktuelle visnings felt ved hjelp av de vise modeller med et minimum av kode blir introdusert (bare bruker settere). Det viktigste fordelen er at du kan teste din UI forretningslogikk mot mange / ulike synspunkter som viser elementer i en horisontal liste eller vertikal liste.

I MVC, snakker vi gjennom grensesnitt (grenser) for å lime forskjellige lag. Controller er en plug-in til vår arkitektur, men det har ingen slik begrensning å pålegge hva som skal vises. I så måte er MVP form av en MVC med et konsept av synspunkter blir pluggbare til styringen i løpet av adaptere.

Håper dette hjelper bedre.

Svarte 25/01/2018 kl. 21:24
kilden bruker

stemmer
0

MVP

MVP står for Model - View-Presenter. Dette kom til bilde tidlig i 2007, hvor Microsoft introduserte Smart Client Windows-programmer.

Presenter fungerer som en tilsynsrolle i MVP som bindende Vis arrangementer og forretningslogikk fra modeller.

Se arrangementet binding vil bli implementert i Presenter fra en visning grensesnitt.

View er initiativtaker for brukerinnganger og deretter delegater til hendelsene Presenter og programleder håndterer event bindinger og få data fra modellene.

Pros: View er å ha bare UI ikke noen logikk Høyt nivå av testbarhet

Cons: Litt komplisert og mer arbeid når gjennomførings event bindinger

MVC

MVC står for Model-View-Controller. Controller er ansvarlig for å lage modeller og rende utsikt med bindingsmodellene.

Controller er initiativtaker, og det bestemmer hvilke se å gjengi.

Pros: Vekt på enkeltansvarsprinsippet Høyt nivå av testbarhet

Cons: Noen ganger for mye arbeidsmengde for Controllers, hvis prøver å gjengi flere visninger i samme kontrolleren.

Svarte 12/01/2016 kl. 04:50
kilden bruker

stemmer
-1

Det enkleste svaret er hvordan utsikten samhandler med modellen. I MVP visningen er bundet til den som presenterer, som fungerer som mellomledd mellom visningen og den modell som tar input fra visningen, får data fra modellen, og deretter utfører en forretningslogikk, og til slutt å oppdatere visningen. I MVC modellen oppdaterer visningen direkte i stedet for å gå tilbake gjennom kontrolleren.

Svarte 16/11/2017 kl. 17:32
kilden bruker

stemmer
-1

Mange vet ikke nøyaktig hva som er forskjellen mellom Controller og programleder i henholdsvis MVC og MVP.

dens en enkel ligning der

MVC Vis = Vis og programleder for MVP

MVP Modell = Controller og modell av MVC

mer info se denne http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

Svarte 31/07/2017 kl. 10:13
kilden bruker

stemmer
-2

Her postet ovenfor er en summering av menneskets svikt og manglende evne til å forstå den enkleste håndtrykk mellom to maskiner. Jeg vil forklare bruke sunn fornuft for å forsøke å vekke deg hele opp fra disse delusional idealisme-er som har funnet veien inn i sinnene til de som ønsker å lage dem. Og så tåpelig som alle disse prosessene høres, er faktisk den Object Model (som er HTML-fil) er ønsket av klientmaskinen. Her er hvordan det hele koker ned.

  1. En link trykkes og en enkelt forespørsel blir sendt av kundens maskin til serveren. Server reagerer på at Request med en Response ved å sende Object Model til Kunden. (Kjent bare som en "Response").
  2. Serveren svarer ved å sende en Object Model (HTML-fil) til klienter Machine (kjent som en full håndtrykk).
  3. Kundene Browser kan nå Render "Vis" ved analyse, lexing / tokenizing, og konvertere det Object Model Markup inn et GUI "View".

Jeg kan bli pensjonert nå, men etter Gosh dere her krangler og diskutere fullstendig meningsløst. Og ærlig uansett hva du kaller et håndtrykk mellom to maskiner kan ikke være noe utenfor en enkel forespørsel, et enkelt svar for objektet "modell" og til slutt Klienter Browser Rendering "View".

Og til slutt, ikke en Vis ikke eksisterer i et håndtrykk. The Object Model er bare Markup for nettleseren til å konvertere til GUI Widget Stiller og Eval Metoder av tre eller flere objektmodeller. HTML, CSS og Javascript. Og uansett hvor mye noen kan si Server gjør noe utenom det vanlige er Horse Dung.

"Server" er ikke "Controller" er det en Directer og bare dirigerer Response ved å sende et objekt "modell" Response. Klientens nettleser (som ville være sannsynlig Controller) oppretter deretter på "View" fra Object "modell" Server har ingenting å gjøre med dette. Datamaskinen språk kan ikke komme inn i Model Object i det hele tatt og heller ikke delegere det. Alt som er er en markering Creator.

Hele dritten er rett og slett en klientsiden Browser "Controller" som analyserer "modell" for å gjengi "View" eller CMV eller MCV (sendt som modell i første orden), og du kan endre det. Men du kan kalle det rett og slett en Request, Response Object Model og Render Vise eller RRMV.

Svarte 31/12/2018 kl. 02:10
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more