Ինչպե՞ս ընտրել iOS- ի համապատասխան ճարտարապետությունը (մաս 2)

MVC, MVP, MVVM, VIPER կամ VIP

Դուք կարող եք խորհրդակցել առաջին մասի հետ այստեղ:

IOS- ի ամենակարևոր ճարտարապետությունները

Համառոտ ակնարկ:

MVC

MVC շերտերը հետևյալն են.

M ՝ բիզնես տրամաբանություն, ցանցի շերտ և տվյալների հասանելիության շերտ

V: UI մակարդակ (UIKit օբյեկտներ, սցենարներ, Xibs)

Գ. Համակարգում է միջնորդությունը մոդելի և տեսակետի միջև:

MVC- ն հասկանալու համար մենք պետք է հասկանանք այն ենթատեքստը, որում այն ​​հորինվել է: MVC- ն ստեղծվել է հին վեբ մշակման օրերին, երբ Views- ը կարգավիճակ չուներ: Հին օրերին զննարկիչը վերբեռնում է ամբողջ HTML- ը ամեն անգամ, երբ կայքում տեսողական փոփոխություն է անհրաժեշտ: Այն ժամանակ գաղափար չկար, որ տեսակետի վիճակը շարունակվում և պահպանվում է:

Օրինակ, կային որոշ մշակողներ, որոնք օգտագործում էին նույն HTML ֆայլերը, PHP- ն ու տվյալների բազան հասանելիությունը: Այսպիսով, MVC- ի հիմնական դրդապատճառը դիտման մակարդակը մոդելի մակարդակից առանձնացնելն էր: Սա բարձրացրեց մոդելի մակարդակի ստուգելիությունը: Իբր MVC- ում դիտման և մոդելի շերտերը չպետք է իմանան միմյանց մասին: Որպեսզի դա հնարավոր դառնա, հնարվեց մի միջանկյալ շերտ, որը կոչվում է վերահսկիչ: Սա այն ՊԵԿ-ն էր, որը կիրառվեց:

MVC ցիկլի օրինակ.

1. Դիտման մակարդակում օգտագործողի գործողություն / օգտագործողի իրադարձություն (օրինակ ՝ «թարմացման գործողություն») գործարկվում է, և այս գործողությունը հաղորդվում է վերահսկիչին
2. Կառավարիչը, որը տվյալներ է ուղարկում մոդելի մակարդակին
3. Վերադարձված տվյալները կարգավորեք կարգավորիչին
4. Կառավարիչը ասում է, որ տեսքը կթարմացնի իր կարգավիճակը նոր տվյալների հետ
5. Դիտեք թարմացրեք դրա վիճակը

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րագրավորման, առևտրի, սահմանափակումների և ենթատեքստային իմաստի մասին է:

Շնորհակալություն ընթերցելու համար: Եթե ​​ձեզ դուր է եկել այս հոդվածը, խնդրում ենք ծափահարել որպեսզի մյուսները նույնպես կարդան այն :)