Kuidas sa lähened arhitektuuri valikule projektis?

Arhitektuuri valiku määrab mahukogus, projekti keerukus, meeskond ning testimise ja hoolduse nõuded.

Peamised arhitektuuritüübid, mida ma Flutteri projektidele kaalun:

• MVC (Model-View-Controller): Lihtne, kuid vähem sobiv keerukate UI-de jaoks, kuna komponendid on tihedalt seotud.
• MVP (Model-View-Presenter): Parandab vastutuse jaotust võrreldes MVC-ga, Presenter suhtleb View-ga läbi liidese.
• MVVM (Model-View-ViewModel): Laialdaselt kasutatav Flutteris. ViewModel sisaldab loogikat ja olekut, View registreerub muudatustele. Sobib hästi testimiseks.
• BLoC (Business Logic Component): Striimidele põhinev lähenemine, oleku ja äriloogika haldamiseks. Tagab puhta koodi, hea testitavuse ja skaleeritavuse.
• Cubit: Lihtsustatud BLoC versioon, ei kasuta sisendandmeteks striime, vaid ainult väljundiks (State). Lihtsam kasutada lihtsate stsenaariumide puhul.
• Provider: Mugav, paindlik ja lihtne pakett oleku ja sõltuvuste haldamiseks. Sageli kasutatakse koos teiste mustritega või iseseisvalt lihtsate rakenduste jaoks.

Valiku protsess:

1. Nõuete analüüs: UI keerukuse, äriloogika, offline-töö vajaduse, väliste teenuste integratsiooni hindamine.
2. Mastaapsus ja hooldatavus: Kui lihtsalt saab funktsionaalsust laiendada ja muudatusi teha tulevikus.
3. Testitavus: Kui lihtsalt saab kirjutada üksus- ja widget-teste.
4. Meeskonna kogemus: Valida arhitektuur, millega meeskond on juba töötanud, kiirendab arendust.
5. Projekti suurus: Väikeste projektide jaoks võib piisata Provider või Cubit/lihtne arhitektuur. Suuremate ja keerulisemate projektide puhul eelistatakse BLoC või MVVM.

Näide, keskmise/keerulise projekti kombinatsioon:

• Globaalse oleku haldamine: Provider või Riverpod (alternatiivina Provider, millel on compile-time turvalisus).
• Funktsiooni-spetsiifiline oleku haldamine: BLoC või Cubit keeruka äriloogika jaoks eraldi moodulites.
• Sõltuvuste süstimine: GetIt või Injectable sõltuvuste haldamiseks.
• Routing: go_router või auto_route.

Oluline aspekt: paindlikkus. Arhitektuur peab olema piisavalt paindlik, et vajadusel seda saaks kohandada või kombineerida erinevate lähenemistega. Peamine on järgida puhta koodi põhimõtteid, nagu SOLID, ning säilitada selge vastutuse jaotus.