Šiuolaikinėms programoms reikia tiek daug funkcijų, kad jų kūrimo procesas išaugo ir tapo sudėtingesnis. Norėdami padėti, galite naudoti architektūrinio dizaino modelį. Jie padeda kurti programas, kurias lengva išbandyti ir prižiūrėti.

Trys populiariausi dizaino modeliai yra MVC, MVP ir MVVM. MVC reiškia modelį, rodinį ir valdiklį, o MVP reiškia modelį, rodinį ir pranešėją, o MVVM - modelį, rodinį ir peržiūros modelį.

Architektūros ir dizaino modeliai

Architektūrinis modelis

Architektūrinis modelis paaiškina ir apibrėžia kai kuriuos esminius programinės įrangos architektūros komponentus. Nors architektūrinis modelis perteikia sistemos vaizdą, tai ne architektūra. Tiesą sakant, tai yra bendras ir pakartotinai naudojamas dažniausiai programinės įrangos architektūros problemos sprendimas tam tikrame kontekste.

Dizaino raštas

Projektavimo modelis yra formalizuota geriausia praktika, kurią galite naudoti norėdami išspręsti įprastas problemas kurdami programą ar sistemą.

Skirtumas tarp architektūros ir dizaino modelio

instagram viewer

Pradėkime nuo bendro termino – modelio. Programinėje įrangoje modelis yra pasikartojanti savybė, leidžianti suskaidyti didžiulę ir sudėtingą struktūrą į mažesnius, paprastesnius komponentus. Galite naudoti šį modelį, kad sukurtumėte bendrą problemų klasės sprendimą.

Kiekviename programinės įrangos kūrimo lygyje naudosite skirtingus įrankius. Mažesniuose lygiuose šie įrankiai yra dizaino modeliai. Architektūriniai modeliai egzistuoja didesniuose lygmenyse ir programavimo paradigmos įgyvendinimo lygmeniu.

Kodėl mums reikia architektūrinio dizaino modelių?

Kurdami programinę įrangą, galite naudoti architektūrinius projektavimo modelius, kad išspręstumėte įprastas problemas. Gera architektūra taip pat gali padėti:

  • Padalinkite sudėtingas užduotis į paprastesnes.
  • Sumažinti klaidas.
  • Sukurkite testuojamą ir prižiūrimą kodą.

Tačiau be architektūrinio modelio gali kilti sunkumų išlaikant programos verslo logiką.

Modelis, Rodinys, ViewModel, Valdiklis ir Pateikėjas

Prieš žiūrėdami į kiekvieną modelį, čia yra terminai, iš kurių jie susideda:

  • Modelis saugo duomenis ir tiesiogiai bendrauja su duomenų baze. Modelis yra dalis, vaizduojanti jūsų duomenis ir programos logiką. Jame apibrėžiamos verslo taisyklės, kuriomis valdomas duomenų tvarkymas, keitimas ar apdorojimas.
  • Žiūrėti rodo modelio duomenis ir yra atsakingas už duomenų atvaizdavimą vartotojo sąsajoje.
  • ViewModel yra išskirtinis MVVM modeliui. Tai yra peržiūros sluoksnio abstrakcija ir taip pat veikia kaip modelio duomenų paketas.
  • Valdiklis yra komponentas, kuris sujungia vaizdą ir modelį.
  • Pranešėjas yra komponentas, kuris egzistuoja tik MVP modelyje. Pateikėjas gauna įvestį iš rodinio komponento ir apdoroja duomenis modelio pagalba.

MVC, MVP ir MVVM modeliai

Modelis-View-Controller Pattern

The MVC architektūrinis modelis buvo pirmasis ir šiandien populiarus žiniatinklio programų srityje. Jis buvo pristatytas aštuntajame dešimtmetyje. Šis modelis leidžia kurti programą, susijusią su rūpesčių atskyrimu (SoC). Tai palengvina pastangas, kurių reikia norint išbandyti, prižiūrėti ir plėtoti programą.

Pagal MVC modelį modelis nesupranta nei vaizdo, nei valdiklio. Modelio stebėtojas gaus įspėjimą, kai pasikeis vaizdas ir valdiklis. Valdiklis padeda maršruto parinkimo procesui prijungti modelį prie atitinkamo rodinio.

Kai kurie MVC modelio pranašumai yra šie:

  • Rūpesčių atskyrimas (labiau sutelktas).
  • Palengvina kodo testavimą ir valdymą.
  • Skatina programos sluoksnių atsiejimą.
  • Geresnis kodo organizavimas ir pakartotinis naudojimas.

Štai kaip veikia MVC:

Dėl SoC MVC gali sumažinti kodo dydį ir sukurti gerą kodą, kuris būtų švarus ir valdomas.

Modelis-View-Presenter Pattern

MVP modelis turi du komponentus su MVC: modelį ir vaizdą. Jis pakeičia valdiklį pranešėju. Pranešėjas, kaip rodo jo pavadinimas, yra naudojamas ką nors pristatyti. Tai leidžia lengviau tyčiotis iš vaizdo.

MVP vedėjas turi „tarpinio žmogaus“ funkcijas, nes visa pristatymo logika yra įstumta į jį. MVP rodinys ir vedėjas taip pat nepriklauso vienas nuo kito ir sąveikauja per sąsają.

Štai kaip veikia MVP modelis:

Pranešėjas gauna informaciją iš vartotojo per rodinį. Tada jis apdoroja vartotojo veiksmus modelio pagalba ir perduoda rezultatus atgal į rodinį. Pranešėjas bendrauja su vaizdu per sąsajas.

Modelis-View-View-Model Pattern

MVVM yra šiuolaikinė MVC evoliucija. Pagrindinis MVVM tikslas yra aiškiai atskirti domeno logiką ir pateikimo sluoksnį. MVVM palaiko dvipusį duomenų susiejimą tarp rodinio ir vaizdo modelio.

MVVM modelis leidžia atskirti kodo rodinį ir modelį. Tai reiškia, kad pasikeitus modeliui rodinio nereikia ir atvirkščiai. Naudodami peržiūros modelį galite atlikti vieneto testavimą ir patikrinti savo loginį elgesį neįtraukdami į savo vaizdą.

Štai MVVM veikimo pavyzdys:

Kada naudoti MVC, MVP ir MVVM

Dabar, kai sužinojote apie kiekvieną modelį, sužinokite, kada juos naudoti.

Kada naudoti MVC

MVC yra tiesiog susirūpinimo atskyrimo įgyvendinimas. Jei jūsų programai reikia atskirti duomenis (modelį), duomenų traiškymą (valdiklį) ir duomenų pateikimą (vaizdą), MVC veiks gerai. MVC taip pat gerai veikia programoje, kurioje duomenų šaltinis ir (arba) duomenų pateikimas gali bet kada pasikeisti.

Kada naudoti MVP

Galite naudoti MVP, kai jūsų programa turi dvikryptį srautą. Jei naudotojui sąveikaujant reikia ko nors paprašyti modelio, o šios užklausos rezultatas iš karto pakeis vartotojo sąsają, apsvarstykite MVP.

Kada naudoti MVVM

Norėsite naudoti MVVM, kai:

  • Turite pasidalinti projektu su dizaineriu, o projektavimo ir tobulinimo darbai gali vykti savarankiškai.
  • Jums reikia savo sprendimų vienetinio testavimo.
  • Turite turėti daugkartinio naudojimo komponentų tiek savo organizacijos projektuose, tiek visuose projektuose.
  • Norite daugiau lankstumo, kad pakeistumėte savo nuomonę, nereikėtų perdaryti kitos kodo bazės logikos.

Kurį modelį turėtumėte pasirinkti?

Pagrindinė priežastis, kodėl verta naudoti dizaino modelį, yra sumažinti sudėtingumą. Tai galite padaryti sumažindami bendrą sudėtingumą arba pakeisdami nepažįstamą sudėtingumą pažįstamu. Jei dizaino modelis negali sumažinti sudėtingumo nė vienu iš šių dviejų būdų, nenaudokite nė vieno iš jų; tai nepridės jokios vertės.

Jei tikrai esate tikri, kad turėtumėte naudoti dizaino modelį, pabandykite sudaryti kontrolinį sąrašą. Remkitės čia matytomis situacijomis ir pasirinkite tinkamiausią savo projektui.