Jaké jsou MVP a MVC a jaký je mezi nimi rozdíl?

hlasů
1k

Při pohledu za RAD (drag-drop a konfiguraci) způsob budování uživatelského rozhraní, které podporují mnoho nástrojů je pravděpodobné, že narazí na třech návrhových vzorů nazývaných Model-View-Controller , Model-View-Presenter a Model-View-ViewModel . Moje otázka má tři součástky:

  1. Jaká témata se tyto vzory řešit?
  2. Jak jsou podobné?
  3. Jak jsou odlišní?
Položena 05/08/2008 v 11:06
zdroj uživatelem
V jiných jazycích...                            


25 odpovědí

hlasů
1k

Model-View-Presenter

V MVP se Presenter obsahuje obchodní logiku UI pro zobrazení. Všechny vyvolání z pohledu delegáta přímo na Presenter. Předvádějícího je také oddělená přímo z pohledu a mluví k němu prostřednictvím rozhraní. To je umožnit uštěpačný View v testu jednotky. Jeden společný atribut MVP je, že tam musí být hodně dvoucestného dispečink. Například, když někdo klikne na tlačítko „uložit“, rutinu události delegáti předvádějícího je „při uložení“ metody. Jakmile je save dokončen, Presenter bude pak volat zpátky View prostřednictvím svého rozhraní, takže View lze zobrazit, že zákrok byl dokončen.

MVP má tendenci být velmi přirozený vzor pro dosažení oddělené prezentaci webových formulářů. Důvodem je to, že zobrazení je vždy nejprve vytvořen pomocí ASP.NET runtime. Můžete se dozvědět více o obou variantách .

Dvě základní varianty

Pasivní View: The View je tak hloupý, jak je to možné a obsahuje téměř nulovou logiku. Předvádějícího je střední člověk, který mluví s výhledem a modelu. The View a Model je zcela chráněna před sebe. Model může vyvolat události, ale Presenter se hlásí k nim pro aktualizaci zobrazení. V pasivním View není závazná žádné přímé údaje, místo toho View vystavuje vlastnosti nastavovací kterou Presenter používá k nastavení data. All stav je řízen v Presenter a ne výhled.

  • Pro: maximum testovatelnost povrch; čisté oddělení View a Model
  • Con: více práce (například všechny vlastnosti seřizovač), jak děláte všechny datové vazby sami.

Dohled Controller: předvádějícího zpracovává uživatelská gesta. Pohled se váže na model přímo prostřednictvím datové vazby. V tomto případě je to přednášejícímu úkolem vydávat modelu do pohledu, takže se může vázat na něj. Předvádějícího bude také obsahovat logiku pro gesta, jako je stisknutí tlačítka, navigace, atd.

  • Pro: využitím Databinding množství kódu se snižuje.
  • Con: je tu méně testovatelné povrch (protože datové vazby), a tam je méně zapouzdření z pohledu, neboť hovoří přímo k modelu.

Model-View-Controller

V MVC je Controller je zodpovědný za určení, které View se zobrazí v reakci na jakoukoli činnost včetně toho, pokud načítání aplikace. Tím se liší od MVP, kde akce trasa přes Pohled na Presenter. V MVC, každá akce z pohledu koreluje s výzvou k řadiči spolu s žalobou. Na webu každá akce zahrnuje výzvu na adresu URL na druhé straně z nichž je řadič, který reaguje. Poté, co že řadič byla dokončena jeho zpracování, vrátí správné zobrazení. Sekvence tímto způsobem po celou dobu životnosti aplikace:

    Akce z pohledu
        -> Výzva k řadiči
        -> Controller Logic
        -> Controller vrací zobrazení.

Jedním z dalších velký rozdíl o MVC je, že zobrazení není přímo vázat na modelu. Pohled jednoduše omítky, a je zcela bez státní příslušnosti. V implementacích MVC View obvykle nebude mít žádnou logiku v kódu za sebou. To je v rozporu s MVP, kde je to nezbytně nutné, protože v případě, že zobrazení nebude delegovat na Presenter, bude to nikdy volán.

Představení modelu

Jedním z dalších vzor podívat se na Prezentace Model vzor. V tomto vzoru není Presenter. Místo toho View se váže přímo na prezentaci modelu. Představení modelu je model vytvořený speciálně pro zobrazení. To znamená, že tento model může vystavit vlastnosti, které by se dalo nikdy postaveny na modelu domény, jak by to bylo porušením oddělení-z-obav. V tomto případě se Prezentace Model váže na modelu domény a může se přihlásit k odběru událostí, pocházejících z tohoto modelu. The View a pak se hlásí k události přicházející z prezentace modelu a odpovídajícím způsobem aktualizuje. Představení modelu může vystavit příkazy, které pohled používá pro vyvolání akce. Výhodou tohoto přístupu je, že můžete v podstatě odstranit kódem na pozadí úplně jako PM zcela zapouzdřuje všechny chování pro zobrazení. Tento model je velmi silným kandidátem pro použití v aplikacích, WPF a je také nazýván Model-View-viewmodel .

Tam je článek MSDN o prezentace modelu a část v Composite Application Pokyny pro WPF (bývalý Prism) o oddělené Prezentace vzorů

Odpovězeno 19/09/2008 v 13:46
zdroj uživatelem

hlasů
381

Jsem blogged o tom, zatímco zpět, cituje na Todd Snyder vynikající příspěvek na rozdílu mezi těmito dvěma :

Zde jsou hlavní rozdíly mezi těmito vzory:

MVP Pattern

  • Pohled je více volně spojený s modelem. Moderátor je zodpovědná za vazbu modelu do pohledu.
  • Snadnější jednotky test, protože interakce s cílem je přes rozhraní
  • Obvykle zobrazení na mapě předvádějícího jedna ku jedné. Komplexní pohledy mohou mít multi moderátory.

MVC vzor

  • Controller jsou založeny na chování a mohou být sdíleny přes zhlédnutí
  • Mohou být zodpovědné za určení, které mohli zobrazit

Je to nejlepší vysvětlení na webu jsem mohl najít.

Odpovězeno 05/08/2008 v 11:21
zdroj uživatelem

hlasů
358

Jedná se o oversimplification z mnoha variant těchto návrhových vzorů, ale je to, jak jsem chtěl přemýšlet o rozdílech mezi těmito dvěma.

MVC

MVC

MVP

zadejte popis obrázku zde

Odpovězeno 06/07/2013 v 23:18
zdroj uživatelem

hlasů
202

Zde jsou ilustrace, které reprezentují komunikační tok

zadejte popis obrázku zde

zadejte popis obrázku zde

Odpovězeno 12/09/2014 v 21:47
zdroj uživatelem

hlasů
147

MVP je ne nutně scénář, kdy View má na starosti (viz Taligent je MVP například).
Považuji za nešťastné, že lidé jsou stále káže to jako vzor (Pohled na starosti), na rozdíl od anti-vzor, protože je v rozporu s „Je to jen pohled“ (pragmatická programátor). „Je to jen pohled“ uvádí, že konečný pohled zobrazí uživateli je sekundární obavy aplikace. Microsoft MVP vzor činí opětovné využití pohledů mnohem obtížnější a pohodlně výmluvy Microsoft značkové doporučovat špatná praxe.

Chcete-li být upřímný, myslím, že podkladová obavy MVC platit za jakékoliv plnění MVP a rozdíly jsou téměř úplně sémantické. Tak dlouho, jak jste po oddělení zájmů mezi pohledu (který zobrazuje data), regulátor (který inicializuje a řídí interakci s uživatelem) a model (základní údaje a / nebo služeb)), pak jste acheiving výhody MVC , Pokud jste acheiving výhody poté, kteří opravdu zajímá, zda je váš vzor MVC, MVP nebo kontrolní řadič? Jediný skutečný vzor zůstává jako MVC, zbytek jsou jen rozdílnou chuť to.

Vezměme si tento velmi zajímavý článek, který podrobně uvádí řadu těchto rozdílných implementací. Můžete si všimnout, že všichni jsou v podstatě dělá to samé, ale trochu jinak.

Osobně si myslím, MVP teprve nedávno re-zaveden jako chytlavý termín buď snížit argumenty mezi sémantickým fanatiky, kteří argumentují, zda je něco opravdu MVC či nikoli, nebo k ospravedlnění Vývojové nástroje Microsofts Rapid Application. Ani jeden z těchto důvodů v mých knihách ospravedlnit svou existenci jako samostatný návrhový vzor.

Odpovězeno 25/08/2008 v 22:22
zdroj uživatelem

hlasů
85

MVP: pohled na starosti.

Pohled, ve většině případů tvoří její moderátor. Moderátor bude interagovat s modelem a manipulovat pohled přes rozhraní. Pohled bude někdy komunikovat s moderátorem, obvykle přes některé rozhraní. To přijde na provádění; chceš pohled na volání metody na moderátora nebo chcete pohled, aby akce moderátor poslouchá? Je scvrkává na toto: Pohled ví o moderátor. Na pohled delegáti moderátor.

MVC: regulátor má na starosti.

Regulátor je vytvořen nebo k němu přistupuje na základě nějaké události / žádost. Regulátor pak vytvoří odpovídající zobrazení a interakci s modelem pro další konfiguraci zobrazení. Je scvrkává na: řídicí jednotka vytváří a spravuje názor; pohled je otrok do řídicí jednotky. Pohled neví o regulátoru.

Odpovězeno 06/08/2008 v 23:51
zdroj uživatelem

hlasů
58

zadejte popis obrázku zde

MVC (Model View Controller)

Vstup je zaměřena na regulátoru nejprve ne pohled. Že vstup by mohlo být přichází z uživatel interakci s stránku, ale může to být také od jednoduchého zadání konkrétní adresy URL do prohlížeče. V každém případě jeho řadič, který je propojen s k nastartování některé funkce. Existuje vztah many-to-one mezi Controller a View. To proto, že jeden ovladač může zvolit různé názory, jež mají být založeny na tyto operace provedeny. Všimněte si na šipku jedním směrem od kontrolora k zobrazení. Důvodem je, že zobrazení nemá žádné znalosti nebo odkaz na regulátoru. Regulátor nemá projít zpět model, takže je znalost mezi zobrazením a očekávaného modelu byly přeneseny do něj, ale ne Controller slouží to.

MVP (Model View Presenter)

Vstupní začíná View, nikoli Presenter. K dispozici je mapování jedna ku jedné mezi zobrazením a přidružené Presenter. The View má odkaz na Presenter. Předvádějícího je také reaguje na události jsou spouštěny z pohledu, takže jeho vědom pohledu ním spojený s. Přednášejícímu aktualizuje zobrazení na základě požadovaných činností, které vykonává na modelu, ale zobrazení není Model vědomi.

Další reference

Odpovězeno 20/12/2015 v 02:10
zdroj uživatelem

hlasů
31

Také stojí za zapamatování je, že existují různé typy MVP stejně. Fowler má zlomené vzoru do dvou - pasivní View a dohled nad Controller.

Při použití Pasivní View, váš pohled typicky implementovat jemnozrnný rozhraní s mapováním vlastností více či méně přímo na podkladní UI widget. Například, můžete mít ICustomerView s vlastnostmi, jako jsou jména a adresy.

Vaše implementace může vypadat nějak takto:

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

Váš Presenter třída bude mluvit s modelem a „mapa“, aby pohledu. Tento postup se nazývá „pasivní View“. Výhodou je, že pohled je snadno testovat, a to je snadnější se pohybovat mezi UI platformy (web, Windows / XAML, atd.). Nevýhodou je, že nemůžete využít věci, jako je databinding (což je opravdu silná v rámcích jako WPF a Silverlight ).

Druhý chuť MVP je kontrolní Controller. V tom případě, že váš pohled může mít vlastnost nazvanou zákazník, který pak opět databound na UI widgety. Nemusíte přemýšlet o synchronizaci a mikro-řídit zobrazení a kontrolní Controller může vstoupit do hry a pomoci v případě potřeby, například s compled logikou interakce.

Třetí „chuť“ na MVP (nebo někdo by možná to samostatný vzor volání) je prezentace Model (nebo někdy označovaná Model-View-viewmodel). Ve srovnání s MVP vy „sloučení“ M a P do jedné třídy. Máte své zákaznické předmět, který vaše UI widgety jsou data vázán, ale máte také další UI-spesific pole jako „IsButtonEnabled“ nebo „IsReadOnly“, etc.

Myslím, že nejlepší zdroj jsem našel na UI architektura je řada příspěvcích udělal Jeremy Miller více než v The Sestavte si svůj vlastní CAB Series Obsah . Zakryl všechny chutě MVP a ukázal kód C # k jejich provádění.

Také jsem blogged o vzoru Model-View-viewmodel v kontextu Silverlight než u YouCard znovu navštívil: Provádění vzoru viewmodel .

Odpovězeno 08/08/2008 v 06:55
zdroj uživatelem

hlasů
31
  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Oba prezentační vzory. Oddělují se závislostí mezi modelem (myslím objekty domény), svou přezdívku / webové stránky (dále jen zobrazení), a jak je váš UI má chovat (Presenter / Controller)
    2. Oni jsou docela podobné v pojetí, lidé inicializovat Presenter / Controller odlišně v závislosti na vkusu.
    3. Skvělý článek o rozdílech je tady . Nejpozoruhodnější je, že MVC vzor má model aktualizuje zobrazení.
Odpovězeno 05/08/2008 v 11:22
zdroj uživatelem

hlasů
15

Obě tyto rámců za cíl oddělit obavy - například interakce se zdrojem dat (model), aplikační logiky (nebo otočení tato data do užitečné informace) (Controller / předvádějícího) a zobrazovacím kódem (View). V některých případech tento model může být také použit pro zapnutí zdroje dat na vyšší úrovni abstrakce stejně. Dobrým příkladem je projekt MVC Storefront .

Tam je diskuse zde o rozdílech mezi MVC vs MVP.

Rozdíl však je, že v aplikaci MVC má tradičně názor a regulátor pracovat s modelem, nikoliv však mezi sebou navzájem.

MVP vzory mají Presenter přístup k modelu a interakci s názorem.

Který uvedl, že ASP.NET MVC je podle těchto definic framework MVP protože Controller přistupuje k modelu k naplnění View, který je určen pro žádnou logiku (zobrazí pouze proměnné poskytované regulátorem).

Aby snad získat představu o rozdílu ASP.NET MVC od MVP, podívejte se na tento MIX prezentaci Scott Hanselman.

Odpovězeno 05/08/2008 v 11:20
zdroj uživatelem

hlasů
12

Oba jsou vzory snaží oddělit prezentační a obchodní logiky, oddělení business logiky z hlediska uživatelského rozhraní

Architektonicky, MVP je Page Controller přístup založený kde MVC je Front Controller přístup založený. To znamená, že v MVP standardní webový formulář stránky životní cyklus je jen umocňuje extrakci obchodní logiky od kódu za sebou. Jinými slovy, stránka je požadavek na http jeden servis. Jinými slovy, MVP IMHO je webový formulář evoluční typ příslušenství. MVC na druhou stranu zcela mění pravidla hry, protože požadavek dostane zachycuje třídy regulátoru před načtením stránky, obchodní logiky je proveden tam a pak na konečný výsledek řadiče zpracování dat právě dumpingové na stránku ( „zobrazení“) v tom, pocit, MVC vzhled (alespoň pro mě), hodně Garantující Controller chuť MVP obohacen o směrování motorem

Oba umožňují TDD a mají stinné stránky a Upsides.

Rozhodnutí o tom, jak si vybrat jednu z nich IMHO by mělo být založeno na tom, kolik času jeden investovala do ASP NET typu webový formulář vývoje webových aplikací. Pokud by se dalo uvažovat o sebe dobře do webových formulářů, bych doporučil MVP. Jestliže jeden by se cítili ne tak dobře ve věcech, jako je strana životního cyklu apod MVC by mohl být způsob, jak jít sem.

Tady je ještě jeden blog post odkaz dává trochu více informací o tomto tématu

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

Odpovězeno 21/09/2008 v 13:32
zdroj uživatelem

hlasů
11

Každý z nich řeší různé problémy a může dokonce být kombinovány dohromady, aby něco podobného níže

Kombinovaný vzor

K dispozici je také kompletní srovnání MVC, MVP a MVVM zde

Odpovězeno 13/03/2017 v 05:54
zdroj uživatelem

hlasů
9

Něco, co nechápu, je, proč vázání dat musí snížit testovatelnosti. Myslím, že pohled je ve skutečnosti vychází z toho, co by bylo možné považovat za jedno nebo více zobrazení databáze, že jo? Tam by mohlo být spojení mezi řádky v různých pohledech. Případně můžeme mluvit objektově orientované namísto relační, ale ve skutečnosti nic nemění - stále máme jednu nebo více odlišných datových subjektů.

Pokud bychom mohli programování jako datové struktury + algoritmů, pak by to bylo nejlepší, aby datové struktury výslovně jak je to možné, a pak se vyvinou algoritmy, které každý závisí na co nejmenší kus dat jak je to možné, s minimálními spojení mezi algoritmy ?

Cítím velmi Java ve stylu FactoryFactoryFactory myšlenkové vzory zde - chceme mít více pohledů, více modelů, více stupňů volnosti všude možně. Je to skoro jako, že je hybnou silou MVC a MVP a kdoví co ještě. Nyní mi dovolte zeptat: jak často je cena, kterou zaplatíte za to (a tam určitě je z hlediska nákladů), stojí za to?

Také nevidím žádné diskusi o tom, jak efektivně řídit stavu mezi požadavky HTTP. Copak jsme se dozvěděli z funkčních lidí (a objemné chyb naléhavými špagety) tento stát je zlo a měly by být minimalizována (a pokud se použije, musí být dobře chápán)?

Vidím spoustu využití z hlediska MVC a MVP bez významné důkazy, že lidé myslet kriticky o nich. Je zřejmé, že problém je, „oni“, já, nebo obojí ...

Odpovězeno 28/01/2009 v 22:11
zdroj uživatelem

hlasů
8

Existuje mnoho odpovědí na otázku, ale cítil jsem, že je třeba pro některé opravdu jednoduchá odpověď jasně porovnávání dva. Zde je diskuse jsem se, když uživatel vyhledává název filmu v MVP a MVC aplikace:

Uživatel: Kliknutím na tlačítko ...

Pohled : Kdo je to? [ MVP | MVC ]

Uživatel: Jen jsem kliknul na tlačítko Hledat ...

Pohled : Ok, počkej chvilku .... [ MVP | MVC ]

( View volání Presenter | Controller ...) [ MVP | MVC ]

Pohled : Hej Presenter | Controller , je uživatel právě klikl na tlačítko vyhledávání, co mám dělat? [ MVP | MVC ]

Presenter | Controller : Hej View , je nějaký vyhledávací dotaz na této stránce? [ MVP | MVC ]

Pohled : Ano ... tady je ... „piano“ [ MVP | MVC ]

Moderátor : Díky View , ... mezitím se dívám nahoru hledaný výraz na modelu , prosím, ukázat mu / jí progress bar [ MVP | MVC ]

( Presenter | Controller volá Model ...) [ MVP | MVC ]

Presenter | Controller : Hej Model , Máte nějakou shodu tohoto výrazu ?: „piano“ [ MVP | MVC ]

Model : Hej Presenter | Controller , dovolte mi, abych zkontrolovat ... [ MVP | MVC ]

( Model dělá dotazu do databáze filmu ...) [ MVP | MVC ]

( Po chvíli ... )

-------------- To je místo, kde MVP a MVC začnou rozcházet ---------------

Model : našel jsem seznam pro vás, Presenter , tady to je v JSON „[{ "name": "Piano Teacher", "rok": 2001}, { "name": "Piano", "rok": 1993} ]“[ MVP ]

Model : Tam je nějaký možný výsledek, Controller . Vytvořil jsem pole proměnné v mém případě, a naplnil ji s výsledkem. Je to jméno je „searchResultsList“ [ MVC ]

( Presenter | Controller díky modelu a dostane zpět na View ) [ MVP | MVC ]

Moderátor : Děkuji za čekání View , našel jsem seznam odpovídající výsledky pro vás a uspořádal je v reprezentativní podobě: [ „Piano Teacher 2001“, „Piano 1993“]. Prosím ukázat, že uživateli ve vertikálním seznamu. Také prosím skrytí postupové lišty nyní [ MVP ]

Controller : Díky za čekání View , jsem požádal model o své vyhledávací dotaz. To říká, že našel seznam odpovídajících výsledků a skladovat je v proměnné s názvem „searchResultsList“ uvnitř jeho instance. Můžete si ji odtamtud. Také prosím skrytí postupové lišty nyní [ MVC ]

Pohled : Děkuji mnohokrát Presenter [ MVP ]

Pohled : Děkuji „Controller“ [ MVC ] (Nyní je pohled se ptát sám sebe: Jak bych měl prezentovat výsledky jsem dostat z modelu ? Uživateli by mělo přijít první nebo poslední rok výroby filmu ... Pokud by to? být ve vertikálním nebo horizontálním seznamu? ...)

V případě, že budete mít zájem, jsem psal sérii článků zabývajících se aplikací architektonické vzory (MVC, MVP, MVVP, čistá architektura, ...), doprovázené GitHub repo zde . I přesto, že vzorek je napsán pro android, může být základní principy aplikovat na jakékoliv médium.

Odpovězeno 06/04/2018 v 13:51
zdroj uživatelem

hlasů
8

V android existuje verze MVC, který je mvp: Co je MVP?

MVP vzor umožňuje oddělit prezentační vrstvy z logiky, takže vše, co o tom, jak funguje rozhraní je oddělen od toho, jak jsme ji zastupují na obrazovce. V ideálním případě by MVP vzor by se dosáhlo, že stejná logika může mít zcela odlišné a vzájemně zaměnitelné názory.

První věc, aby objasnila, že MVP není architektonický vzor, ​​je odpovědný pouze za prezentační vrstvy. V každém případě je vždy lepší, aby jej použít pro svoji architekturu, která jej nepoužívají vůbec.

Příkladem MVP je https://github.com/antoniolg/androidmvp

Co je to MVC? MVC architektura je jedním z nejstarších modelů jsou k dispozici pro dosažení oddělení znepokojení. MVC se skládá ze tří vrstev, totiž, Model, View, a řadič.

Classic MVC existovaly v době, kdy každý control / přístroj, který existoval na obrazovce byla považována za hloupý a každý ovládací prvek je spárován s vlastním řadičem pro správu uživatelských interakcí, ke kterým došlo na nich. Takže pokud existují 10 gadgets, pak 10 řadiče musí existovat. V tomto případě každý gadget se počítá jako zobrazení. Příchod GUI systémů Windows změnil tento obrázek. Vztah Control-Controller zastaral. Controls získala inteligenci reagovat na akce iniciované uživatelem. Ve světě Windows, pohled je povrch, na kterém jsou splněny všechny ovládací prvky / gadgets, proto je potřeba pouze jeden řadič. Pohled může přijímat události a dosáhnout řadiče pomůže udělat další zpracování.

Ukázkový kód pro MVC v android http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

Rozdíl mezi oběma je k dispozici zde http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Nyní Z mé zkušenosti je nutné použít MVP pro android založený projekt, protože vylepšená verze MVC modelu.

Odpovězeno 02/07/2016 v 07:15
zdroj uživatelem

hlasů
8

Použil jsem i MVP a MVC ai když jsme jako vývojáři mají tendenci soustředit se na technické rozdíly obou modelů bod pro MVP v IMHO je mnohem souvisejících s snadnost přijetí, než cokoliv jiného.

Když jsem pracoval v týmu, který již jako dobré zázemí na webu tvoří vývoj styl je mnohem snazší zavést MVP než MVC. Řekl bych, že MVP v tomto scénáři je rychlá výhra.

Moje zkušenost mi říká, že pohybující se tým z webových formulářů na MVP a pak z MVP pro MVC je poměrně snadné; přechodu z webových formulářů na MVC je mnohem obtížnější.

I tady nechat odkaz na sérii článků kamarád zveřejnila o MVP a MVC.

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

Odpovězeno 02/01/2009 v 11:35
zdroj uživatelem

hlasů
7

MVP pohled čerpá data z moderátorka, která čerpá a připravuje / normalizuje data z modelu, zatímco v MVC regulátor čerpá data z modelu a nastavit pomocí stisknutí v zobrazení.

MVP můžete mít jednotný pohled pracuje s několika typy moderátorů a jednoho moderátor pracuje s různými více pohledů.

MVP obvykle používá nějaký závazného rámce, jako závazného rámce Microsoft WPF nebo různých závazných rámců pro HTML5 a Java.

V těchto rámcích je UI / HTML5 / XAML je vědom toho, co vlastnost moderátor každého uživatelského rozhraní displejů prvků, takže když se vážou pohled na přednášejícího, pohled vypadá pro vlastnosti a ví, jak čerpat z nich data a jak které mají být nastaveny, když je hodnota změněna v uživatelském rozhraní uživatelem.

Takže, je-li například model je auto, pak moderátor je nějaký druh automobilu moderátor, odhaluje auto vlastnosti (rok, kávovar, sedadla atd) do pohledu. Pohled ví, že textové pole s názvem ‚automobilka‘ potřebuje zobrazit vlastnost moderátor Maker.

Potom se může vázat k názoru, mnoho různých typů moderátor, všichni musí mít Maker vlastnost - může se jednat o letadlem, vlakem, nebo co vůbec, pohled nestará. Pohled čerpá data z moderátor - bez ohledu na to, které - tak dlouho, jak to zavádí dohodnutou rozhraní.

Tento závazný rámec, pokud si ji svléknout, je to vlastně :-) regulátor

A tak se můžete podívat na MVP jako evoluce MVC.

MVC je skvělé, ale problém je, že obvykle ji kontroluje per view. Ovladač A ví, jak nastavit zorné pole A. Pokud teď chcete Pohled A zobrazit data modelu B, je třeba regulátor vědět modelu B, nebo potřebujete řadič přijímat objekt s rozhraním - který je jako MVP pouze bez vázání, nebo budete muset přepsat UI nastavený kód Controller B.

Závěr - MVP a MVC jsou oba DECOUPLE UI vzorů, ale MVP obvykle používá rámec vázání, která je MVC pod ním. TAK MVP je na vyšší úrovni architektury než MVC a obalu vzoru shora MVC.

Odpovězeno 07/06/2013 v 22:16
zdroj uživatelem

hlasů
6

Můj skromný krátký pohled: MVP je na velkých měřítkách a MVC pro malé váhy. S MVC, někdy cítím V a C mohou být Viděl dvě strany jedné nedělitelné součásti spíše přímo vázaný na M a jedna nevyhnutelně klesne na to, když jde dolů na kratší měřítek, jako jsou ovládací prvky uživatelského rozhraní a základních widgetů. Na této úrovni granularity, MVP nedává smysl. Když se člověk naopak jít do větších měřítek, vlastní rozhraní se stává ještě důležitější, to samé s jednoznačným přiřazením odpovědnosti, a tady je MVP.

Na druhou stranu, toto měřítko pravidlo palce, může vážit jen velmi málo, pokud charakteristiky platforma podporuje nějaký druh vztahů mezi složkami, jako u webu, kde se zdá být jednodušší provádět MVC, více než MVP.

Odpovězeno 20/02/2013 v 17:55
zdroj uživatelem

hlasů
5

Model-View-Controller

MVC je vzor pro architekturu softwarové aplikace. To oddělit aplikační logiku do tří samostatných částí, propagaci modularitu a snadnou spolupráci a opětovné použití. To také umožňuje vytvářet pružnější a příjemné na iterations.It odděluje aplikace do následujících částí:

  • Modely pro manipulace s daty a obchodní logiky
  • Regulátory pro manipulaci s uživatelské rozhraní a aplikace
  • Pohledy pro manipulaci grafických objektů a úpravy uživatelského rozhraní

Aby to bylo trochu jasnější, pojďme si představit jednoduchý nákupní seznam aplikací. Jediné, co chci, je seznam názvů, množství a cenu každé položky musíme koupit tento týden. Níže popíšeme, jak bychom mohli realizovat některé z těchto funkcí pomocí MVC.

zadejte popis obrázku zde

Model-View-Presenter

  • Modelu jsou data, která se zobrazí v pohledu (user interface).
  • Pohled je rozhraní, které zobrazuje data (model) a trasy uživatelské příkazy (Akce) na Presenter působit na tato data. Pohled má zpravidla odkaz na jeho Presenter.
  • Presenter je „middle-man“ (hrál regulátorem v MVC) a obsahuje odkazy na oba, pohled a model. Vezměte prosím na vědomí, že slovo „Model“ je zavádějící. Mělo by být spíše obchodní logika, která načítá nebo manipuluje model . Například: Pokud máte databázi ukládání uživatele v tabulce databáze a váš pohled chce zobrazit seznam uživatelů, pak Presenter bude mít odkaz na vaše databáze obchodní logiky (jako DAO) z, kde Presenter bude dotazovat seznam uživatelů.

Pokud chcete vidět vzorek s jednoduchou implementaci zkontrolujte tento GitHub příspěvek

Konkrétním workflow dotazování a zobrazovat seznam uživatelů z databáze by mohla fungovat takto: zadejte popis obrázku zde

Jaký je rozdíl mezi MVC a MVP vzory?

MVC vzor

  • Controller jsou založeny na chování a mohou být sdíleny přes zhlédnutí

  • Mohou být zodpovědné za určení, které zobrazení na displeji (Front Controller Pattern)

MVP Pattern

  • Pohled je více volně spojený s modelem. Moderátor je zodpovědná za vazbu modelu do pohledu.

  • Snadnější jednotky test, protože interakce s cílem je přes rozhraní

  • Obvykle zobrazení na mapě předvádějícího jedna ku jedné. Komplexní pohledy mohou mít multi moderátory.

Odpovězeno 29/11/2017 v 10:14
zdroj uživatelem

hlasů
3

Existuje mnoho verzí MVC, tato odpověď je o původní MVC v Smalltalk. Stručně řečeno, je to Obraz MVC vs MVP

Tato diskuse droidcon NYC 2017 - Clean app design s architekturou komponent to objasňuje

zadejte popis obrázku zde zadejte popis obrázku zde

Odpovězeno 09/09/2015 v 02:34
zdroj uživatelem

hlasů
0

Tam je to pěkné video ze strýčka Boba, kde stručně vysvětluje MVC & MVP koncem.

Co si myslím, je MVP je vylepšená verze MVC, kde si v podstatě oddělit obavy o tom, jak budeš ukazují data, která máte. Presenter zahrnuje trochu obchodní logiky svého uživatelského rozhraní a hovoří prostřednictvím rozhraní, které usnadňuje vyzkoušet své UI obchodní logiku v různých pohledech. MVC stále mluví přes rozhraní (hranice), aby lepidlo vrstev, ale nemá takové omezení uložit UI prezentační logiku. Jiné, než to, že nemám opravdu vidět žádné větší rozdíly.

Odpovězeno 25/01/2018 v 21:24
zdroj uživatelem

hlasů
0

MVP

MVP představuje model - View- Presenter. To přišlo na obrázek na začátku roku 2007, kdy Microsoft představil Smart Client okna aplikace.

Moderátor působí jako dozorčí roli v MVP, která závazným zobrazení událostí a obchodní logiky z modelů.

Zobrazit událost vazba bude realizován v Presenter z pohledu rozhraní.

Pohled je iniciátorem uživatelských vstupů a poté delegáty událostí na Presenter a moderátor zpracovává vazby událostí a získat data z modelů.

Pros: View má pouze rozhraní není žádný logiky Vysoká testovatelnosti

Nevýhody: Bit složitější a pracnější při provádění vázání události

MVC

MVC je zkratka pro Model-View-Controller. Controller je zodpovědný za vytváření modelů a rendering názory se závaznými modelů.

Regulátor je iniciátorem a rozhodne, které mohli učinit.

Pros: Důraz na Single odpovědnosti principu high úrovně testovatelnosti

Nevýhody: Někdy příliš mnoho pracovní zátěž pro kontroléry, pokud se snaží poskytnout různé pohledy do stejného řadiče.

Odpovězeno 12/01/2016 v 04:50
zdroj uživatelem

hlasů
-1

Nejjednodušší odpověď je, jak se pohled na interakci s modelem. MVP je model vázán na moderátora, který je zodpovědný za aktualizaci zobrazení. V MVC model aktualizuje pohled přímo.

Odpovězeno 16/11/2017 v 17:32
zdroj uživatelem

hlasů
-2

Zveřejněny zde nahoře je součtem neúspěchu a neschopnosti člověka pochopit nejjednodušší handshake mezi dvěma stroji. Budu vysvětlovat používání zdravého rozumu, aby se pokusili vás všechny probudit z nich bludy idealismus to, že si našly cestu do myslí těch, kteří chtějí, aby jejich vytvoření. A jak hloupé, jak všechny tyto procesy zvuk, fakt je objektový model (což je HTML soubor) je na žádost klienta. Zde je, jak to všechno se scvrkává.

  1. Jeden hypertextový odkaz je stisknuto a jeden Požadavek se posílá prostřednictvím počítače klienta na server. Server odpoví na tuto žádost s odpovědí zasláním objektový model Klientovi. (Známý jednoduše jako „Response“).
  2. Server odpoví vysláním Object Model (HTML soubor) klientům Machine (označovaný jako Full Handshake).
  3. Klienti Browser nyní Render na „View“ na základě analýzy, lexing / tokenizaci a převedením tento objekt Model Markup do GUI „View“.

I mohou být nyní v důchodu, ale Gosh vy tady se hádají a diskutujeme naprostý nesmysl. A upřímně, bez ohledu na to, co říkáte Handshake mezi dvěma stroji nemůže být nic mimo jediného požadavku, jediná odezva objektu „model“ a konečně klienti prohlížeče skýtat „View“.

A na závěr, je pohled neexistuje v Handshake. Objektový model je pouze značkami pro prohlížeče pro přechod na GUI Widget Sady a eval metody třemi nebo více modelů objektů. HTML, CSS a JavaScript. A bez ohledu na to, jak moc někdo může říci Server dělá něco neobvyklého je koňského trusu.

Dále jen „Server“ není „Controller“ je Directer a jen směruje odpověď zasláním objekt „Model“ Response. Prohlížeč klienta (což by bylo pravděpodobně Controller), pak vytvoří „Zobrazit“ z objektu „Model“ Server nemá nic společného s tím. Váš počítač jazykem nemůže dostat do objektového modelu vůbec ani delegovat. Vše, co to je je Markup Creator.

Celá nepořádek je prostě na straně klienta Browser „Controller“, který analyzuje dále jen „Model“ k tomu, aby „View“ nebo CMV nebo MCV (odeslané jako model v první řadě), a nemůžete ji změnit. Ale můžete volat pouze na request, response objektový model a Render View nebo RRMV.

Odpovězeno 31/12/2018 v 02:10
zdroj uživatelem

hlasů
-2

Mnoho lidí neví, co přesně je rozdíl mezi regulátorem a moderátor v MVC a MVP resp.

jeho jednoduchá rovnice kde

MVC View = Zobrazení a Presenter na MVP

MVP Model = regulátor a model MVC

Více informací naleznete na této http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

Odpovězeno 31/07/2017 v 10:13
zdroj uživatelem

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