Jak přistupujete k výběru architektury pro projekt?

Výběr architektury je určen rozsahem, složitostí projektu, týmem a požadavky na testovatelnost a udržovatelnost.

Hlavní typy architektur, které zvažuji pro Flutter projekty:

• MVC (Model-View-Controller): Jednoduché, ale méně vhodné pro složité UI kvůli těsně propojeným komponentám.
• MVP (Model-View-Presenter): Zlepšuje rozdělení odpovědností ve srovnání s MVC, Presenter komunikuje s View přes rozhraní.
• MVVM (Model-View-ViewModel): Široce používané ve Flutter. ViewModel obsahuje logiku a stav, View se přihlašuje ke změnám. Dobré pro testování.
• BLoC (Business Logic Component): Přístup založený na Streamech, pro správu stavu a obchodní logiky. Zajišťuje čistý kód, dobrou testovatelnost a škálovatelnost.
• Cubit: Zjednodušená verze BLoC, nepoužívá Streamy pro vstupy, pouze pro výstupy (Stav). Snadnější použití v jednoduchých scénářích.
• Provider: Užitečný, flexibilní a jednoduchý balíček pro správu stavu a závislostí. Často používaný v kombinaci s jinými vzory nebo samostatně pro jednoduché aplikace.

Proces výběru:

1. Analýza požadavků: Hodnocení složitosti UI, obchodní logiky, potřeby offline práce, integrace s externími službami.
2. Škálovatelnost a udržovatelnost: Jak snadno bude možné rozšiřovat funkce a provádět změny v budoucnu.
3. Testovatelnost: Jak snadno bude možné psát unit a widget testy.
4. Zkušenosti týmu: Výběr architektury, se kterou má tým zkušenosti, urychlí vývoj.
5. Velikost projektu: Pro malé projekty může stačit Provider nebo Cubit/jednoduchá architektura. Pro velké a složité projekty jsou vhodnější BLoC nebo MVVM.

Příklad kombinace přístupů pro středně velký/složitý projekt:

• Globální správa stavu: Provider nebo Riverpod (alternativa k Provider s compile-time bezpečností).
• Specifická správa stavu funkcionality: BLoC nebo Cubit pro složitou obchodní logiku v rámci modulů.
• Injektáž závislostí: GetIt nebo Injectable pro správu závislostí.
• Routing: go_router nebo auto_route.

Důležitý aspekt: přizpůsobivost. Architektura musí být dostatečně flexibilní, aby bylo možné ji přizpůsobit nebo kombinovat různé přístupy podle potřeby. Hlavním cílem je dodržování principů čistého kódu, jako je SOLID, a udržení jasného oddělení odpovědností.