Běžné architektury Android (MVC vs MVP vs MVVM)

Než přejdeme k architekturám, pojďme si tento termín ujasnit.
Třída / objekt Boha: Třída, která má vysoký počet komponent a komponenty jsou spojeny. To je velmi špatný nápad a musí se jim za každou cenu vyhnout. Je to architektonický vzor.

MVC: Model View Controller

Modelka:
1. Představuje datové modely.
2. Spravuje stavy dat
3. Má obchodní logiku

Pohled:
1. Způsob, jakým reprezentujeme naše data, např. Zobrazení / rozložení v Androidu.
2. Vykreslí uživatelské rozhraní.

Ovladač:
1. Zvládá interakce uživatelů s naší aplikací.
2. Komunikační kanál mezi modelem a pohledem.
např. fragmenty / aktivity v systému Android.

Vývojový diagram MVC bude vypadat takto:

Uživatel spolupracuje s uživatelským rozhraním a ovladač je informován prostřednictvím zobrazení. Na základě interakce uživatele řadič modifikuje určité modely. Modely provádějí nějakou obchodní logiku a vracejí aktualizovaný stav dat modelu regulátoru. Řadič pak může aktualizovat UI podle nového stavu dat přijatého z Modelu.

Pohled získá vstup uživatele a požádá správce o zpracování vstupu uživatele.
Řadič získá vstup z pohledu, na základě toho, zda se uživatel rozhodl skrýt / zobrazit zprávu. Řadič volá model k aktualizaci stavu dat (zpráva zde).
Model aktualizuje model na základě vstupu z řadiče. Obsahuje tedy tuto obchodní logiku.
Řadiče získávají aktualizovaná data a podle toho aktualizují uživatelské rozhraní.

MVP: Model View Presenter

Modelka:
Stejné jako ve vzoru MVC.

Pohled:
1. Způsob, jakým reprezentujeme naše data, např. Zobrazení / rozložení a také aktivity / fragmenty v systému Android.
2. Implementuje rozhraní pro akce předvádějícího.

Moderátor:
1. Nemá žádný vztah k pohledům (na rozdíl od MVC).
2. Operace jsou vyvolány našimi názory.
3. Zobrazení jsou aktualizována prostřednictvím rozhraní View.

Vývojový diagram MVP bude vypadat takto:

Ačkoli vývojový diagram vypadá stejně jako MVC, rozdíl je v tom, jak VIew a Presenters / Controllers vzájemně komunikují.

V MVP pohledy a přednášející interagují přes rozhraní (na rozdíl od MVC). Předvádějící provádějí nějakou akci na rozhraní, které je implementováno v pohledech, a proto se pohled aktualizuje.

Model tedy zůstává stejný (jako v MVC).
Předvádějící zde pouze provádí akce rozhraní a nemá žádné znalosti o pohledech, které se pokouší aktualizovat.
Pohledy implementující toto rozhraní tedy aktualizují uživatelské rozhraní.

Je to mnohem lepší než MVC, protože zde má moderátor NO ANDROID API a lze jej snadno testovat.
Zobrazení lze testovat pomocí espressa atd., Abyste zjistili, zda jsou zobrazení aktualizována nebo ne.

Názory jsou tedy dost hloupé. Získají data od moderátora a podle toho aktualizují komponenty uživatelského rozhraní.

MVVM - Model View ViewModel

Dále minimalizuje kód vázání pohledu, tj. Jak se pohled váže na data modelu.

Když mluvíme v ekosystému Android, používá knihovnu vázání dat od Googlu a vazební logika pohledu je implementována do rozložení XML.

Modelka:
Stejné jako ve vzoru MVC / MVP.

Pohled:
1. Stejné jako ve vzoru MVC / MVP.

ViewModel:
1. Obsahuje Model.
2. Pro hodnoty aktualizace používá pozorovatelné hodnoty.
3. Při aktualizaci hodnoty získají příslušné pohledy aktualizace (používá knihovnu vázání dat).

Vývojový diagram MVP bude vypadat takto:

Pohled tedy dostává uživatelské interakce a oznámí model pohledu.
Nyní ViewModel aktualizuje model i pozorovatelný (což vyvolá změnu hodnoty). Dále rozhraní ViewModel aktualizuje uživatelské rozhraní (rozložení XML) přímo.

Pohled tj. Soubor XML bude vypadat takto:

Jak je vidět, TextView se zde může přímo aktualizovat jeho text, protože se mění hodnota zprávy.

Porovnání mezi MVC / MVP / MVVM:

Řadiče (činnosti v systému Android) mají vysokou závislost na systému Android, na rozdíl od MVP a MVVM, a proto je snadné testovat jednotky v MVP / MVVM.

XML se však pro účely vazby dat stává komplexnějším v MVVM.