Kaip prieinate architektūros pasirinkimą projektui?

Architektūros pasirinkimas priklauso nuo apimties, projekto sudėtingumo, komandos ir testavimo bei palaikymo reikalavimų.

Pagrindiniai architektūros tipai, kuriuos svarstau Flutter projektuose:

• MVC (Model-View-Controller): Paprasta, bet mažiau tinkama sudėtingiems UI dėl glaudžiai susijusių komponentų.
• MVP (Model-View-Presenter): Pagerina atsakomybės pasidalijimą, palyginti su MVC, Presenter sąveikauja su View per sąsają.
• MVVM (Model-View-ViewModel): Plačiai naudojama Flutter. ViewModel turi logiką ir būseną, View prenumeruoja pokyčius. Tinka testavimui.
• BLoC (Business Logic Component): Srauto pagrindu, valdyti būseną ir verslo logiką. Užtikrina švarų kodą, gerą testavimą ir mastelį.
• Cubit: Supaprastinta BLoC versija, nenaudoja srautų įvesties duomenims, tik išvesties (State). Paprastesnė naudoti paprastiems scenarijams.
• Provider: Patogus, lankstus ir paprastas paketas būsenos ir priklausomybių valdymui. Dažnai naudojamas kartu su kitais modeliais arba savarankiškai paprastoms programėlėms.

Pasirinkimo procesas:

1. Reikalavimų analizė: Vertinimas UI sudėtingumo, verslo logikos, offline darbo poreikio, išorinių paslaugų integracijos.
2. Mastelio ir palaikymo galimybės: Kiek lengvai galėsime plėsti funkcionalumą ir daryti pakeitimus ateityje.
3. Testavimo galimybė: Kiek lengvai galėsime rašyti vienetinius ir widget testus.
4. Komandos patirtis: Pasirinkti architektūrą, su kuria komanda turi patirties, tai pagreitins kūrimą.
5. Projekto dydis: Mažiems projektams pakanka Provider arba Cubit/paprastos architektūros. Dideliems ir sudėtingesniems geriau tinka BLoC arba MVVM.

Pavyzdys, vidutinio/sudėtingo projekto derinys:

• Globalus būsenos valdymas: Provider arba Riverpod (kaip alternatyva Provider su kompiliatoriaus saugumu).
• Funkcijos specifinis būsenos valdymas: BLoC arba Cubit sudėtingai verslo logikai atskiruose moduliuose.
• Priklausomybių injekcija: GetIt arba Injectable priklausomybių valdymui.
• Routing: go_router arba auto_route.

Svarbus aspektas: lankstumas. Architektūra turi būti pakankamai lanksti, kad ją būtų galima pritaikyti arba derinti su skirtingais požiūriais, jei reikia. Svarbiausia — laikytis švaraus kodo principų, tokių kaip SOLID, ir išlaikyti aiškų atsakomybės pasidalijimą.