Ինչպե՞ս եք մոտենում նախագծի ճարտարապետության ընտրությանը:

Արշավի ընտրությունը որոշվում է ծավալով, նախագծի բարդությամբ, թիմով և թեստավորման և պահպանման պահանջներով:

Նախագծերի համար հիմնական ճարտարապետության տեսակները, որոնք ես դիտարկում եմ Flutter նախագծերի համար՝

• MVC (Model-View-Controller): Պարզ, բայց քիչ հարմար է բարդ UI-ների համար, քանի որ բաղադրիչները խիստ կապված են:
• MVP (Model-View-Presenter): բարելավում է պատասխանատվության բաժանումը՝ համեմատած MVC-ի, Presenter-ը շփվում է View-ի հետ ինտերֆեյսի միջոցով:
• MVVM (Model-View-ViewModel): Շատ տարածված է Flutter-ում: ViewModel-ը պարունակում է տրամաբանությունը և վիճակը, View-ը գրանցվում է փոփոխությունների համար: Հարմար է թեստավորման համար:
• BLoC (Business Logic Component): Ապարատ, հիմնված Stream-ների վրա, վիճակի և բիզնես տրամաբանության կառավարման համար: Օգնում է պահպանել մաքուր կոդ, լավ թեստավորման և ընդլայնելիության:
• Cubit: Պարզեցված տարբերակ BLoC-ի, չի օգտագործում Stream-ներ մուտքային տվյալների համար, միայն ելքային (State): Հեշտ է օգտագործել պարզ սցենարների համար:
• Provider: Հարմար, ճկուն և պարզ փաթեթ վիճակի և կախվածությունների կառավարման համար: Շատ հաճախ օգտագործվում է այլ մոդելների հետ կամ ինքնուրույն՝ պարզ հավելվածների համար:

Ընտրության գործընթացը՝

1. Տեղեկատվության վերլուծություն: UI բարդության, բիզնես տրամաբանության, օֆլայն աշխատանքի անհրաժեշտության, արտաքին ծառայությունների ինտեգրման գնահատում:
2. Մասշտաբայնություն և պահպանելիություն: Ինչքան հեշտ կլինի ընդլայնել ֆունկցիոնալությունը և կատարել փոփոխություններ ապագայում:
3. Թեստավորման հնարավորությունը: Ինչքան հեշտ կլինի գրել միավոր և widget թեստեր:
4. Թիմի փորձը: Արշավի ընտրությունը, որի հետ թիմը ունի փորձ, արագացնի զարգացման գործընթացը:
5. Նախագծի չափը: Փոքր նախագծերի համար կարող է բավարար լինել Provider կամ Cubit/պարզ ճարտարապետություն: Մեծ և բարդ նախագծերի համար ավելի նախընտրելի են BLoC կամ MVVM:

Օրինակ՝ միջին/բարդ նախագծի համար տարբերակների համադրություն՝

• Աշխարհագրական վիճակի կառավարման համակարգ: Provider կամ Riverpod (ընտրանք՝ Provider-ի փոխարեն՝ compile-time անվտանգությամբ):
• Հատկապես ֆունկցիայի համար վիճակի կառավարման համակարգ: BLoC կամ Cubit՝ բիզնես տրամաբանության բարդության համար՝ առանձին մոդուլներում:
• Վերաբերումների ներմուծում: GetIt կամ Injectable՝ կախվածությունների կառավարման համար:
• Routing: go_router կամ auto_route:

Մեծ կարևորություն ունի՝ ճկունություն: Արշավը պետք է լինի բավականին ճկուն, որպեսզի անհրաժեշտության դեպքում այն կարող է հարմարեցվել կամ համակցվել տարբեր մոտեցումների հետ: Հիմնականը՝ հետևել մաքուր կոդի սկզբունքներին՝ SOLID, և պահպանել պատասխանատվության հստակ բաժանումը: