Ինչպե՞ս ընտրել iOS- ի համապատասխան ճարտարապետությունը (մաս 2)
MVC, MVP, MVVM, VIPER կամ VIP
Դուք կարող եք խորհրդակցել առաջին մասի հետ այստեղ:
IOS- ի ամենակարևոր ճարտարապետությունները
Համառոտ ակնարկ:
MVC
MVC շերտերը հետևյալն են.
M ՝ բիզնես տրամաբանություն, ցանցի շերտ և տվյալների հասանելիության շերտ
V: UI մակարդակ (UIKit օբյեկտներ, սցենարներ, Xibs)
Գ. Համակարգում է միջնորդությունը մոդելի և տեսակետի միջև:
MVC- ն հասկանալու համար մենք պետք է հասկանանք այն ենթատեքստը, որում այն հորինվել է: MVC- ն ստեղծվել է հին վեբ մշակման օրերին, երբ Views- ը կարգավիճակ չուներ: Հին օրերին զննարկիչը վերբեռնում է ամբողջ HTML- ը ամեն անգամ, երբ կայքում տեսողական փոփոխություն է անհրաժեշտ: Այն ժամանակ գաղափար չկար, որ տեսակետի վիճակը շարունակվում և պահպանվում է:
Օրինակ, կային որոշ մշակողներ, որոնք օգտագործում էին նույն HTML ֆայլերը, PHP- ն ու տվյալների բազան հասանելիությունը: Այսպիսով, MVC- ի հիմնական դրդապատճառը դիտման մակարդակը մոդելի մակարդակից առանձնացնելն էր: Սա բարձրացրեց մոդելի մակարդակի ստուգելիությունը: Իբր MVC- ում դիտման և մոդելի շերտերը չպետք է իմանան միմյանց մասին: Որպեսզի դա հնարավոր դառնա, հնարվեց մի միջանկյալ շերտ, որը կոչվում է վերահսկիչ: Սա այն ՊԵԿ-ն էր, որը կիրառվեց:
MVC ցիկլի օրինակ.
- Դիտման մակարդակում օգտագործողի գործողություն / օգտագործողի իրադարձություն (օրինակ ՝ «թարմացման գործողություն») գործարկվում է, և այս գործողությունը հաղորդվում է վերահսկիչին
- Կառավարիչը, որը տվյալներ է ուղարկում մոդելի մակարդակին
- Վերադարձված տվյալները կարգավորեք կարգավորիչին
- Կառավարիչը ասում է, որ տեսքը կթարմացնի իր կարգավիճակը նոր տվյալների հետ
- Դիտեք թարմացրեք դրա վիճակը
Apple MVC
IOS- ում View Controller- ը զուգակցվում է UIKit- ի և կյանքի ցիկլի դիտման հետ, ուստի այն զուտ MVC չէ: Այնուամենայնիվ, MVC սահմանման մեջ ոչինչ չկա ասելու, որ վերահսկիչը չի կարող իմանալ տեսակետը կամ մոդելավորել հատուկ իրականացումը: Դրա հիմնական նպատակն է առանձնացնել մոդելի մակարդակի պարտականությունները դիտակետից, որպեսզի մենք կարողանանք դրանք նորից օգտագործել և մեկուսացնել ստուգել մոդելի մակարդակը:
ViewController– ը պարունակում է դիտում և պատկանում է մոդելին: Խնդիրն այն է, որ մենք ViewController- ին գրում ենք և՛ վերահսկիչի կոդը, և՛ դիտման կոդը:
MVC- ն հաճախ առաջացնում է այն, ինչ կոչվում է Massive View Controller խնդիր, բայց դա տեղի է ունենում միայն բավական բարդությամբ ծրագրերում և դառնում է լուրջ բիզնես:
Գոյություն ունեն մի քանի մեթոդներ, որոնք մշակողը կարող է օգտագործել դիտումների կարգավորիչը ավելի պարզ դարձնելու համար: Մի քանի օրինակներ.
- Արդյունահանեք VC տրամաբանությունը այլ դասերի համար, ինչպիսիք են աղյուսակի դիտման մեթոդների տվյալների աղբյուրը և պատվիրել այլ ֆայլերի համար `օգտագործելով պատվիրակի նախագծման օրինակը:
- Ստեղծեք կազմի պարտականությունների ավելի հստակ տարանջատում (օրինակ ՝ VC- ն բաժանելով երեխաների դիտման կառավարման սարքերի):
- Օգտագործեք համակարգողի նախագծման օրինակը `վիրտուալ հսկիչում նավիգացիոն տրամաբանության իրականացման պատասխանատվությունը վերացնելու համար
- Օգտագործեք DataPresenter փաթաթման դաս, որն ամփոփում է տրամաբանությունը և տվյալների մոդելը վերափոխում է տվյալների արդյունքի, որոնք ներկայացնում են վերջնական օգտագործողին ներկայացված տվյալները:
MVC- ն ընդդեմ MVP- ի
MVC- ն մի քայլ առաջ էր, բայց այն դեռ նշանավորվեց որոշ բաների վերաբերյալ բացակայությամբ կամ լռությամբ:
Այդ ընթացքում Համաշխարհային սարդոստայնը աճում էր, և շատ բան զարգանում էր մշակողների համայնքում: Օրինակ ՝ ծրագրավորողները սկսեցին օգտագործել Ajax- ը և միանգամից ամբողջ HTML էջի փոխարեն բեռնեցին էջերի միայն մասեր:
MVC- ում, իմ կարծիքով, չկա որևէ նշում, որ վերահսկիչը չպետք է իմանա View- ի (բացակայության) յուրահատուկ իրականացումը:
HTML- ը դիտման շերտի մի մասն էր, և շատ դեպքեր այնքան հիմար էին: Որոշ դեպքերում, այն պարզապես իրադարձություններ է ստանում օգտագործողից և ցուցադրում է GUI- ի տեսողական բովանդակությունը:
Քանի որ վեբ էջերի մասերը բեռնված էին մասերի, այս սեգմենտացիան հանգեցրեց տեսողության վիճակի պահպանմանը և ներկայացման տրամաբանության համար պարտականությունների տարանջատման ավելի մեծ անհրաժեշտությանը:
Ներկայացման տրամաբանությունն այն տրամաբանությունն է, որը վերահսկում է, թե ինչպես է ցուցադրվում օգտվողի միջերեսը և ինչպես են ինտերֆեյսի տարրերը փոխազդում միմյանց հետ: Որպես օրինակ `հսկիչ տրամաբանությունն է այն բանի, թե երբ բեռնման ցուցիչը պետք է սկսի ցուցադրել / անիմացնել, և երբ այն դադարի ցույց տալ / կենդանացնել:
MVP- ում և MVVM- ում դիտման շերտը պետք է լինի այնքան անխռով, որ պարունակում է ոչ մի տրամաբանություն կամ բանականություն, իսկ iOS- ում դիտման կարգավորիչը պետք է լինի դիտման շերտի մաս: Այն փաստը, որ View- ը համր է, նշանակում է, որ նույնիսկ ներկայացման տրամաբանությունը մնում է View- ի հարթությունից դուրս:
MVC- ի հետ կապված խնդիրներից մեկն այն է, որ պարզ չէ, թե ուր պետք է գնա ներկայացման տրամաբանությունը: Նա պարզապես լռում է այդ մասին: Ներկայացման տրամաբանությունը պետք է լինի դիտման հարթության՞ն, թե՞ մոդելի հարթության:
Եթե մոդելի դերը միայն «հում տվյալների» տրամադրումն է, դա նշանակում է, որ տեսադաշտում նշված կոդը հետևյալն է.
Հաշվի առեք հետևյալ օրինակը. Մենք ունենք անուն և ազգանուն ունեցող օգտվող: Տեսքում մենք պետք է օգտագործողի անունը ցույց տանք որպես «Ազգանուն, անուն» (օրինակ ՝ «Ֆլորես, Տիագո»):
Եթե մոդելի դերը «հում տվյալների» տրամադրումն է, դա նշանակում է, որ տեսադաշտում նշված կոդը հետևյալն է.
թող firstName = userModel.getFirstName () թող lastName = userModel.getLastName () nameLabel.text = Ազգանուն + «,« + Անուն
Սա նշանակում է, որ View- ի պատասխանատվությունն է կարգավորել օգտագործողի ինտերֆեյսի տրամաբանությունը: Այնուամենայնիվ, դա անհնար է դարձնում օգտագործողի ինտերֆեյսի տրամաբանության միավորի ստուգումը:
Մյուս մոտեցումն է `թույլ տալ, որ մոդելը ցույց տա միայն այն տվյալները, որոնք պետք է ցուցադրվեն և բիզնեսի տրամաբանությունը թաքցնի դիտումից: Բայց հետո մենք ունենք մոդելներ, որոնք կարգավորում են ինչպես բիզնեսի տրամաբանությունը, այնպես էլ օգտագործողի ինտերֆեյսի տրամաբանությունը: Դա փորձարկվող մարմին կլիներ, բայց հետո մոդելը անուղղակիորեն կախված է տեսքից:
թող անուն = userModel.getDisplayName () nameLabel.text = անուն
Դա պարզ է MVP- ի համար, և ներկայացման տրամաբանությունը մնում է ներկայացուցչի մակարդակում: Սա մեծացնում է ներկայացուցչի մակարդակի ստուգելիությունը: Այժմ մոդելի և ներկայացնողի շերտը կարելի է փորձարկել առանց որևէ խնդրի:
Սովորաբար MVP իրականացումներում դիտումը թաքնված է ինտերֆեյսի / պրոտոկոլի ետևում, և հաղորդավարում չպետք է հղումներ լինեն UIKit- ի:
Մեկ այլ բան, որը պետք է նշել, անցողիկ կախվածություններն են:
Եթե վերահսկիչը որպես կախվածություն ունի բիզնեսի շերտ, իսկ գործարար շերտը ՝ որպես կախվածություն, տվյալների հասանելիության շերտ ունի, վերահսկիչը տվյալների փոխանցման շերտի համար ունի անցողիկ կախվածություն: Քանի որ MVP ներդրումները սովորաբար օգտագործում են պայմանագիր (արձանագրություն) բոլոր մակարդակների միջև, անցողիկ կախվածություններ չկան:
Տարբեր շերտերը նույնպես փոխվում են տարբեր պատճառներով և տարբեր տեմպերով: Այսպիսով, եթե դուք մի մակարդակ եք փոխում, սա ենթադրաբար չի առաջացնում երկրորդական էֆեկտներ / խնդիրներ մյուս մակարդակներում:
Արձանագրություններն ավելի կայուն են, քան դասերը: Տեղեկամատյանները չեն պարունակում իրականացման որևէ մանրամասներ և կապված չեն պայմանագրերի հետ: Հետևաբար, հնարավոր է փոխել մեկ մակարդակի իրականացման մանրամասները ՝ առանց մյուս մակարդակների վրա ազդելու:
Պայմանագրերը (արձանագրությունները) տարանջատում են ստեղծում շերտերի միջև:
MVP vs MVVM
MVP- ի և MVVM- ի հիմնական տարբերություններից մեկն այն է, որ MVP- ում հաղորդավարը միջերես է տալիս դիտմանը, իսկ MVVM- ում դիտումը կենտրոնացած է տվյալների և իրադարձությունների փոփոխությունների վրա:
MVP- ում մենք ստեղծում ենք ձեռնարկի հղում հաղորդավարի և դիտման միջև ՝ օգտագործելով ինտերֆեյս / պրոտոկոլներ: MVVM- ում մենք իրականացնում ենք տվյալների ավտոմատ կապակցում RxSwift- ով, KVO- ով կամ մեխանիզմով `հանածոներով և փակմամբ:
MVVM- ում ViewModel- ի և View- ի միջև մեզ նույնիսկ պայմանագիր (օրինակ `Java ինտերֆեյս / iOS պրոտոկոլ) պետք չէ, քանի որ մենք սովորաբար շփվում ենք Observer Design Pattern- ի միջոցով:
MVP- ն օգտագործում է պատվիրակի օրինակը, քանի որ ներկայացնող շերտը հրամաններ է պատվիրում դիտման շերտին: Հետեւաբար, նա պետք է ինչ-որ բան իմանա տեսարանի մասին, նույնիսկ եթե դա պարզապես միջերեսի / արձանագրության ստորագրությունն է: Մտածեք ificationանուցման կենտրոնի և TableView պատվիրակների տարբերության մասին: Ificationանուցման կենտրոնը կապի ալիք ստեղծելու համար միջերեսերի կարիք չունի: Այնուամենայնիվ, TableView պատվիրակները օգտագործում են արձանագրություն, որը դասերը պետք է իրականացնեն:
Մտածեք լիցքի ցուցիչի ներկայացման տրամաբանության մասին: MVP- ում վարողը վարում է ViewProtocol.showLoadingIndicator- ը: MVVM- ում ViewModel- ում կարող է լինել isLoading հատկություն: Դիտման շերտը օգտագործում է տվյալների ավտոմատ պարտադիր ճանաչում, երբ այս հատկությունը փոխվում և թարմացվում է: MVP- ն ավելի գրավիչ է, քան MVVM- ը, քանի որ ներկայացնողը հրամաններ է տալիս:
MVVM- ն ավելի շատ տվյալների փոփոխության մասին է, քան ուղղակի պատվերների, և տվյալների փոփոխությունները մենք կապում ենք թարմացումները դիտելու համար: Երբ մենք օգտագործում ենք RxSwift և ֆունկցիոնալ ռեակտիվ ծրագրավորման պարադիգմը MVVM- ի հետ միասին, մենք կոդը դարձրել ենք էլ ավելի պակաս համոզիչ և ավելի դեկլարատիվ:
MVVM- ն ավելի հեշտ է ստուգել, քան MVP- ն, քանի որ MVVM- ն օգտագործում է Observer Design Pattern- ը, որը տվյալների փոխանցում է բաղադրիչների միջև անջատված եղանակով: Այսպիսով, մենք կարող ենք ստուգել ՝ պարզապես նայելով տվյալների փոփոխություններին ՝ համեմատելով երկու օբյեկտները, այլ ոչ թե ծաղրելով մեթոդի զանգերը ՝ տեսքի և հաղորդավարի հաղորդակցությունը ստուգելու համար:
Հ.Գ.- Ես մի քանի թարմացում արեցի այն իրի մասին, որն այն մեծապես աճեցրեց: Ուստի անհրաժեշտ էր այն բաժանել երեք մասի: Երրորդ մասը կարող եք կարդալ այստեղ:
Երկրորդ մասն ավարտվում է այստեղ: Բոլոր արձագանքները ողջունելի են: Երրորդ մասը VIPER- ի, VIP- ի, Ռեակտիվ mingրագրավորման, առևտրի, սահմանափակումների և ենթատեքստային իմաստի մասին է: