Articles

Architektonický vzor MVP

v tomto článku se dozvíme něco o vzoru MVP, který je zděděn od vzoru MVC. Ale rozhodně, má některé změny ve srovnání s MVC vzorem. Takže pochopíme, jak ji používat, jak rozlišovat mezi vzorem MVC a vzorem MVP.

začněme.

  • Analýza Problému
  • Definice MVP Vzor
  • Při použití
  • Výhody & Nevýhodou
  • Balení

Analýza Problému

upozornění, že se narodil MVP vzor je stejný jako s MVC vzor. Ale MVP se používá, aby se zabránilo některé nevýhody MVC vzoru, jako je:

  • v MVC vzoru, pohled a Model mohou být vzájemně na sebe. Obvykle tedy validujeme data z modelu nebo používáme datovou logiku. Takže to ztěžuje automatické testování jednotek.
  • je relevantní pro zabezpečení.

Definice MVVM Vzor

Podle wikipedia.com máme definice MVP vzor:

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.

A MVP vzor vznikl na počátku 1990 na Taligent, společný podnik Apple, IBM, a Hewlett-Packard.

níže je uveden obsah každé části ve vzoru MVP.

  • Model má entity a služby.

    entity se používají k tomu, aby obsahovaly data, která jsou mapována s tabulkou v databázi pro využití některých jiných důvodů.

    služby, lze použít vzor DAO nebo vzor úložiště, jsou tenké vrstvy mezi aplikační vrstvou a vrstvou pro přístup k datům. Obvykle spravují CRUD operace s databází v místní nebo vzdálené.

  • zobrazení má povinnosti, které interagují s uživateli.

    neobsahuje žádnou logiku. Bude směrovat uživatelské vstupy a příkazy (události) do presenteru.

    zobrazení má obvykle odkaz na svého presentera.

  • Presenter je prostřední částí mezi zobrazením a modelem. Bude hrát stejnou roli jako řadič v MVC vzoru.

    Všechny obchodní logika, data logic, potvrďte vstup, obdrží události z Pohledů, převádí data z View na Model nebo Model pro Zobrazení je realizován v Presenteru.

    ve srovnání s View a controllerem ve vzoru MVC jsou View a Presenter přítomné ve vzoru MVP od sebe plně odděleny a komunikují prostřednictvím rozhraní. (Moderátor komunikovat s Výhledem přes Zobrazení rozhraní, to znamená, že Moderátor může plnit všechny prezentace a navigační úkoly bez jakékoliv závislosti na skutečné uživatelské ROZHRANÍ používané technologie)

    A máme sekvenční diagram MVP vzor:

Při použití

  • Naše obrazovky již bi-directional-flow, to znamená, že interakce uživatele je třeba požádat o něco z našeho Modelu, a výsledek této žádosti bude mít vliv na Zobrazení.

  • zobrazení ovlivněné aktualizacemi z modelu je velmi omezené.

  • vzor MVP se nepoužívá v případě, kdy je uživatelské rozhraní aktualizováno bez uživatelských interakcí, jako je aktualizace uživatelského rozhraní při události v modelu, je tento přístup blíže MVVM více než MVP.

Výhody & Nevýhodou

  1. Výhody
    • Cílem není komunikovat přímo s Modelem. To izoluje implementaci View lépe než v MVC a umožňuje snadnější automatizované testování jednotky presenteru a modelu.

    • možnost změnit uživatelské rozhraní z webu na okno nebo mobil je velmi snadná.

    • Nízké údržbu náklady.

  2. Nevýhody
    • Presenter má tendenci expandovat do obrovského vševědoucí třídy, pokud jsme dostatečně opatrní a neporušují naše kódem podle Jednotného Odpovědnost Principu.

    • zvýšená složitost.

    • Extra křivka učení.

Některé vzory, které jsou relevantní pro MVP vzor

  • Application Controller – Pokud moderátorů komunikovat s aplikací správce, moderátoři nepotřebují stránce tok a obrazovky navigační logiku. To usnadňuje aktualizaci toku stránky.

  • Observer pattern

Balení

  • koncový uživatel pracuje pouze s názorem.

  • jeden pohled je mapován pouze na jeden Presenter.

  • Zobrazit reference Presenter ale nemá žádný odkaz na Model. A moderátor si je také vědom názoru, který s ním souvisí.

  • vzor umožňuje obousměrnou komunikaci mezi View a Presenterem.

  • existují dvě další implementace vzoru MVP, jako je pasivní pohled a supervizní řadič.

    • pasivní zobrazení je zcela ovládáno Presenterem. Implementací pasivního zobrazení MVP je mnohem snazší zvládnout souběžnost a multithreading.

    • Při dohledu nad Presenter, View komunikuje přímo s Modelem provádět žádné jednoduché datové vazby, které mohou být deklarativně definované, bez Moderátora. Moderátor aktualizuje Model. Změní stav zobrazení pouze tehdy, když je vyžadována složitá logika uživatelského rozhraní, kterou nelze deklarativně specifikovat.

    • Porovnat s ostatními variantami MVP, jako Pasivní Pohled, Dohled nad Moderátorka vzor dělá jednodušší kód s vyšší prioritou, než kompletní testovatelnosti. Vzor presenteru Supervising vyžaduje méně kódu než jiné vzory MVP, protože používá vazbu dat. Kód se snáze udržuje, protože jednoduché změny uživatelského rozhraní nevyžadují změny kódu v presenteru k aktualizaci zobrazení.

viz:

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)