Algengar Android arkitektúr (MVC vs MVP vs MVVM)

Áður en við förum yfir í arkitektúr skulum við skilja þetta hugtak.
God Class / Object: Flokkur sem er með mikinn fjölda íhluta og íhlutirnir eru tengdir. Þetta er mjög slæm hugmynd og verður að forðast þær á öllum kostnaði. Það er byggingarlistarmynstur.

MVC: stjórnandi fyrirsjá

Gerð:
1. Táknar gagnalíkönin.
2. Umsjón með gagnaríkjunum
3. Er með viðskiptatækni

Útsýni:
1. Hvernig við táknum gögnin okkar t.d. Skoðanir / skipulag í Android.
2. Gerir HÍ.

Stjórnandi:
1. Meðhöndlar samskipti notenda við forritið okkar.
2. Samskiptaleið milli líkansins og útsýnisins.
t.d. brotin / Starfsemin í Android.

MVC flæðiritið mun líta út eins og:

Notandinn hefur samskipti við HÍ og stjórnandi fær tilkynningu um það. Byggir á notendasamskiptum breytir stjórnandinn ákveðnum gerðum. Líkön framkvæma einhverja viðskiptatækni og skila uppfærðu líkanagagnaástandi til stjórnandans. Stýringarmaðurinn getur síðan uppfært HÍ í samræmi við nýja gagnatilvikið eins og það hefur borist frá Model.

Útsýnið fær notandainntakið og biður stjórnandann að sjá um inntak notandans.
Stjórnandi fær inntak frá View, byggt á því hvort notandinn kaus að fela / skoða skilaboðin. Stjórnandi hringir í líkan til að uppfæra Gagnaástandið (skilaboð hér).
Líkanið uppfærir líkanið út frá inntaki stjórnandans. Þannig inniheldur það þessa viðskiptalögfræði.
Stjórnendur fá uppfærð gögn og uppfæra HÍ í samræmi við það.

MVP: Model View Presenter

Gerð:
Sama og í MVC mynstri.

Útsýni:
1. Hvernig við táknum gögnin okkar t.d. Skoðanir / skipulag sem og athafnir / brot í Android.
2. Mun útfæra tengi fyrir aðgerðir kynningarinnar.

Kynnir:
1. Hefur engin tengsl við skoðanirnar (Ólíkt MVC).
2. Aðgerðir eru kallaðar fram af skoðunum okkar.
3. Skoðanir eru uppfærðar með viðmóti View.

MVP flæðiritið mun líta út eins og:

Þrátt fyrir að flæðirit sé svipað og MVC er munurinn á því hvernig VIew og Presenters / Controllers hafa samskipti sín á milli.

Í MVP hafa skoðanir og nútíminn samskipti við tengi (ólíkt MVC). Kynnir framkvæma nokkrar aðgerðir á viðmótinu, sem er útfært í Views og þess vegna verður útsýnið uppfært.

Svo líkanið er það sama (og í MVC).
Kynnirinn hér framkvæmir bara Interface aðgerðirnar og hefur enga þekkingu á þeim skoðunum sem hann er að reyna að uppfæra.
Þannig að skoðanirnar sem innleiða það viðmót uppfæra HÍ.

Það er miklu betra en MVC þar sem kynnirinn er með ENGA ANDROID API og auðvelt er að prófa það.
Hægt er að prófa skoðanirnar með því að nota espresso osfrv til að sjá hvort skoðanirnar eru uppfærðar eða ekki.

Þannig eru skoðanirnar ansi heimskar. Þeir fá gögn frá kynniranum og uppfærir HÍ íhluti í samræmi við það.

MVVM- Skoða View Model

Það lágmarkar enn frekar bindiskóðann fyrir útsýni, þ.e.a.s hvernig útsýnið er bundið við fyrirmyndargögnin.

Talandi í Android vistkerfinu notar það gagnabindingasafnið frá Google og bindandi rökfræði View er útfærð í XML skipulaginu.

Gerð:
Sama og í MVC / MVP mynstri.

Útsýni:
1. Sama og í MVC / MVP mynstri.

ViewModel:
1. Það inniheldur líkanið.
2. Notar sýnilegt gildi til að uppfæra gildi.
3. Við gildi uppfærsluna munu viðeigandi skoðanir fá uppfærslur (notar gagnabindandi bókasafn).

MVP flæðiritið mun líta út eins og:

Þannig að útsýnið fær notendaviðskipti og mun tilkynna skoðunarlíkanið.
Nú mun ViewModel uppfæra líkanið sem og Observable (sem mun kalla á gildi breytinganna). Næst mun ViewModel viðmót uppfæra UI (XML skipulag) beint.

Þannig að útsýnið, þ.e.a.s. XML skrá, mun líta út eins og:

Svo sem sýnt er á TextView hér getur verið uppfært beint texta þess þar sem gildi skilaboðanna breytist.

Samanburður á milli MVC / MVP / MVVM:

Stýringar (athafnir í Android) eru mjög háðir Android, ólíkt MVP og MVVM, og þess vegna er auðvelt að prófa það í MVP / MVVM.

Hins vegar verður XML flóknara í MVVM í gagnabindandi tilgangi.