తగిన iOS ఆర్కిటెక్చర్‌ను ఎలా ఎంచుకోవాలి (పార్ట్ 2)

MVC, MVP, MVVM, VIPER లేదా VIP

మీరు ఇక్కడ మొదటి భాగాన్ని సంప్రదించవచ్చు.

అతి ముఖ్యమైన iOS నిర్మాణాలు

సంక్షిప్త అవలోకనం.

ఎంవిసి

MVC పొరలు క్రింది విధంగా ఉన్నాయి:

M: బిజినెస్ లాజిక్, నెట్‌వర్క్ లేయర్ మరియు డేటా యాక్సెస్ లేయర్

V: UI స్థాయి (UIKit వస్తువులు, స్టోరీబోర్డులు, Xibs)

సి: మోడల్ మరియు వీక్షణ మధ్య మధ్యవర్తిత్వాన్ని సమన్వయం చేస్తుంది.

ఎంవిసిని అర్థం చేసుకోవాలంటే అది కనిపెట్టిన సందర్భం అర్థం చేసుకోవాలి. వీక్షణలకు స్థితి లేనప్పుడు పాత వెబ్ అభివృద్ధి రోజుల్లో MVC కనుగొనబడింది. పాత రోజుల్లో, వెబ్‌సైట్‌లో మనకు దృశ్యమాన మార్పు అవసరమైన ప్రతిసారీ బ్రౌజర్ అన్ని HTML ని రీలోడ్ చేస్తుంది. ఆ సమయంలో, వీక్షణ స్థితిని కొనసాగించి, సేవ్ చేస్తున్నట్లు తెలియదు.

ఉదాహరణకు, అదే HTML ఫైల్‌లు, PHP మరియు డేటాబేస్ యాక్సెస్‌ను ఉపయోగించిన కొంతమంది డెవలపర్లు ఉన్నారు. కాబట్టి వీక్షణ స్థాయిని మోడల్ స్థాయి నుండి వేరు చేయడం ఎంవిసి యొక్క ప్రధాన ప్రేరణ. ఇది మోడల్ స్థాయి యొక్క పరీక్షా సామర్థ్యాన్ని పెంచింది. MVC లో వీక్షణ మరియు మోడల్ పొరలు ఒకదానికొకటి తెలియదని ఆరోపించారు. ఇది సాధ్యమయ్యేలా, నియంత్రిక అని పిలువబడే ఇంటర్మీడియట్ పొర కనుగొనబడింది. ఇది వర్తించబడిన SRP.

MVC చక్రానికి ఉదాహరణ:

  1. వీక్షణ స్థాయిలో వినియోగదారు చర్య / వినియోగదారు ఈవెంట్ (ఉదా. "నవీకరణ చర్య") ప్రేరేపించబడుతుంది మరియు ఈ చర్య నియంత్రికకు తెలియజేయబడుతుంది
  2. మోడల్ స్థాయికి డేటాను పంపే నియంత్రిక
  3. తిరిగి వచ్చిన డేటాను నియంత్రికకు మోడల్ చేయండి
  4. కొత్త డేటాతో వీక్షణ దాని స్థితిని నవీకరిస్తుందని నియంత్రిక చెప్పారు
  5. నవీకరణను చూడండి

ఆపిల్ ఎంవిసి

IOS లో, వ్యూ కంట్రోలర్ UIKit మరియు జీవితచక్ర వీక్షణతో కలిసి ఉంటుంది, కాబట్టి ఇది స్వచ్ఛమైన MVC కాదు. ఏదేమైనా, MVC నిర్వచనంలో నియంత్రిక వీక్షణ లేదా మోడల్ నిర్దిష్ట అమలును తెలుసుకోలేదని చెప్పడానికి ఏమీ లేదు. మోడల్ స్థాయి యొక్క బాధ్యతలను వీక్షణ స్థాయి నుండి వేరు చేయడం దీని ప్రధాన ఉద్దేశ్యం, తద్వారా మేము వాటిని తిరిగి ఉపయోగించుకోవచ్చు మరియు మోడల్ స్థాయిని ఒంటరిగా పరీక్షించవచ్చు.

వ్యూ కంట్రోలర్ వీక్షణను కలిగి ఉంది మరియు మోడల్‌ను కలిగి ఉంది. సమస్య ఏమిటంటే మేము కంట్రోలర్ కోడ్ మరియు వ్యూ కోడ్ రెండింటినీ వ్యూ కంట్రోలర్‌కు వ్రాస్తున్నాము.

MVC తరచుగా భారీ వీక్షణ నియంత్రిక సమస్యగా పిలువబడుతుంది, అయితే ఇది తగినంత సంక్లిష్టత కలిగిన అనువర్తనాల్లో మాత్రమే సంభవిస్తుంది మరియు తీవ్రమైన వ్యాపారంగా మారుతుంది.

వ్యూ కంట్రోలర్‌ను స్పష్టంగా చేయడానికి డెవలపర్ ఉపయోగించే కొన్ని పద్ధతులు ఉన్నాయి. కొన్ని ఉదాహరణలు:

  • టేబుల్ వ్యూ పద్ధతుల యొక్క డేటా సోర్స్ వంటి ఇతర తరగతుల కోసం VC తర్కాన్ని సంగ్రహించండి మరియు ప్రతినిధి రూపకల్పన నమూనాను ఉపయోగించి ఇతర ఫైళ్ళకు ప్రతినిధి.
  • కూర్పు బాధ్యతల యొక్క స్పష్టమైన విచ్ఛిన్నతను సృష్టించండి (ఉదా., పిల్లల వీక్షణ నియంత్రణలుగా VC ని విభజించడం).
  • వర్చువల్ కంట్రోలర్‌లో నావిగేషన్ లాజిక్‌ను అమలు చేసే బాధ్యతను తొలగించడానికి కోఆర్డినేటర్ డిజైన్ నమూనాను ఉపయోగించండి
  • డేటాప్రెజెంటర్ రేపర్ క్లాస్‌ని ఉపయోగించండి, అది తర్కాన్ని కలుపుతుంది మరియు డేటా మోడల్‌ను తుది వినియోగదారుకు అందించిన డేటాను సూచించే డేటా అవుట్‌పుట్‌గా మారుస్తుంది.

MVC వర్సెస్ MVP

మీరు MVP నుండి రేఖాచిత్రాన్ని చూడగలిగినట్లుగా, MVC చాలా పోలి ఉంటుంది

MVC ఒక అడుగు ముందుకు ఉంది, కానీ ఇది ఇప్పటికీ కొన్ని విషయాల గురించి లేకపోవడం లేదా నిశ్శబ్దం ద్వారా గుర్తించబడింది.

ఈ సమయంలో, వరల్డ్ వైడ్ వెబ్ పెరిగింది మరియు డెవలపర్ కమ్యూనిటీలో చాలా విషయాలు అభివృద్ధి చెందాయి. ఉదాహరణకు, ప్రోగ్రామర్లు అజాక్స్ ఉపయోగించడం ప్రారంభించారు మరియు మొత్తం HTML పేజీకి బదులుగా పేజీల భాగాలను మాత్రమే లోడ్ చేసారు.

MVC లో, నా అభిప్రాయం ప్రకారం, వీక్షణ (లేకపోవడం) యొక్క నిర్దిష్ట అమలును కంట్రోలర్‌కు తెలియదని సూచనలు లేవు.

HTML వీక్షణ పొరలో భాగం, మరియు చాలా సందర్భాలు చాలా తెలివితక్కువవి. కొన్ని సందర్భాల్లో, ఇది వినియోగదారు నుండి సంఘటనలను స్వీకరిస్తుంది మరియు GUI యొక్క దృశ్యమాన కంటెంట్‌ను ప్రదర్శిస్తుంది.

వెబ్ పేజీల భాగాలు భాగాలుగా లోడ్ చేయబడినందున, ఈ విభజన వీక్షణ స్థితిని పరిరక్షించడానికి దారితీసింది మరియు ప్రదర్శన తర్కం కోసం బాధ్యతలను వేరుచేయడానికి ఎక్కువ అవసరం ఉంది.

ప్రెజెంటేషన్ లాజిక్ అనేది వినియోగదారు ఇంటర్‌ఫేస్ ఎలా ప్రదర్శించబడుతుందో మరియు వినియోగదారు ఇంటర్‌ఫేస్ అంశాలు ఒకదానితో ఒకటి ఎలా సంకర్షణ చెందుతాయో నియంత్రించే తర్కం. లోడింగ్ సూచిక ఎప్పుడు చూపించడం / యానిమేట్ చేయడం మొదలుపెట్టాలి మరియు ఎప్పుడు చూపించడం / యానిమేట్ చేయాలి అనే నియంత్రణ తర్కం ఒక ఉదాహరణ.

MVP మరియు MVVM లలో, వీక్షణ పొర చాలా తెలివితక్కువదిగా ఉండాలి, అందులో ఎటువంటి తర్కం లేదా తెలివితేటలు ఉండవు, మరియు iOS లో వ్యూ కంట్రోలర్ వీక్షణ పొరలో భాగంగా ఉండాలి. వీక్షణ మూగగా ఉంది అంటే ప్రదర్శన తర్కం కూడా వ్యూ విమానం వెలుపల ఉంది.

MVC తో ఉన్న సమస్యలలో ఒకటి, ప్రదర్శన తర్కం ఎక్కడికి వెళ్ళాలో స్పష్టంగా తెలియదు. అతను దాని గురించి మౌనంగా ఉంటాడు. ప్రదర్శన తర్కం వీక్షణ స్థాయిలో లేదా మోడల్ స్థాయిలో ఉందా?

మోడల్ యొక్క పాత్ర "ముడి డేటా" ను మాత్రమే అందించాలంటే, వీక్షణలోని కోడ్ ఈ క్రింది విధంగా ఉందని అర్థం:

కింది ఉదాహరణను పరిశీలించండి: మాకు మొదటి మరియు చివరి పేరు ఉన్న వినియోగదారు ఉన్నారు. వీక్షణలో మేము వినియోగదారు పేరును "చివరి పేరు, మొదటి పేరు" (ఉదా. "ఫ్లోర్స్, టియాగో") గా చూపించాలి.

"ముడి" డేటాను అందించడం మోడల్ పాత్ర అయితే, వీక్షణలోని కోడ్ ఈ క్రింది విధంగా ఉందని అర్థం:

firstName = userModel.getFirstName () lastName = userModel.getLastName () nameLabel.text = చివరి పేరు + “,“ + మొదటి పేరు

వినియోగదారు ఇంటర్‌ఫేస్ తర్కాన్ని నిర్వహించడం వీక్షణ బాధ్యత అని దీని అర్థం. అయినప్పటికీ, ఇది వినియోగదారు ఇంటర్‌ఫేస్ తర్కాన్ని యూనిట్ పరీక్షించడం అసాధ్యం చేస్తుంది.

మరొక విధానం ఏమిటంటే, మోడల్ చూపించాల్సిన డేటాను మాత్రమే చూపించటానికి అనుమతించడం మరియు వ్యాపార తర్కాన్ని చూడకుండా దాచడం. కానీ అప్పుడు మాకు వ్యాపార తర్కం మరియు వినియోగదారు ఇంటర్‌ఫేస్ తర్కం రెండింటినీ నిర్వహించే నమూనాలు ఉన్నాయి. ఇది పరీక్షించదగిన ఎంటిటీ అవుతుంది, కానీ అప్పుడు మోడల్ పరోక్షంగా ఆధారపడి ఉంటుంది.

name = userModel.getDisplayName () nameLabel.text = name ని అనుమతించండి

ఇది MVP కి స్పష్టంగా ఉంది మరియు ప్రెజెంటేషన్ లాజిక్ ప్రెజెంటర్ స్థాయిలో ఉంది. ఇది ప్రెజెంటర్ స్థాయి యొక్క పరీక్షా సామర్థ్యాన్ని పెంచుతుంది. ఇప్పుడు మోడల్ మరియు ప్రెజెంటర్ పొరను ఎటువంటి సమస్యలు లేకుండా పరీక్షించవచ్చు.

సాధారణంగా MVP అమలులలో వీక్షణ ఇంటర్ఫేస్ / ప్రోటోకాల్ వెనుక దాగి ఉంటుంది మరియు ప్రెజెంటర్లో UIKit గురించి సూచనలు ఉండకూడదు.

గమనించదగ్గ మరో విషయం ఏమిటంటే ట్రాన్సిటివ్ డిపెండెన్సీలు.

నియంత్రిక ఒక వ్యాపార పొరను డిపెండెన్సీగా కలిగి ఉంటే మరియు వ్యాపార పొరలో డేటా యాక్సెస్ పొరను డిపెండెన్సీగా కలిగి ఉంటే, నియంత్రిక డేటా యాక్సెస్ లేయర్‌కు ట్రాన్సిటివ్ డిపెండెన్సీని కలిగి ఉంటుంది. MVP అమలులు సాధారణంగా అన్ని స్థాయిల మధ్య ఒక ఒప్పందాన్ని (ప్రోటోకాల్) ఉపయోగిస్తాయి కాబట్టి, ట్రాన్సిటివ్ డిపెండెన్సీలు లేవు.

వేర్వేరు పొరలు వేర్వేరు కారణాల వల్ల మరియు వేర్వేరు రేట్ల వద్ద కూడా మారుతాయి. కాబట్టి మీరు ఒక స్థాయిని మార్చుకుంటే, ఇది ఇతర స్థాయిలలో ద్వితీయ ప్రభావాలను / సమస్యలను కలిగించదు.

తరగతుల కంటే ప్రోటోకాల్‌లు స్థిరంగా ఉంటాయి. లాగ్‌లలో ఎటువంటి అమలు వివరాలు లేవు మరియు ఒప్పందాలతో అనుసంధానించబడవు. అందువల్ల, ఒక స్థాయి అమలు వివరాలను ఇతర స్థాయిలను ప్రభావితం చేయకుండా మార్చడం సాధ్యపడుతుంది.

ఒప్పందాలు (ప్రోటోకాల్‌లు) పొరల మధ్య డికప్లింగ్‌ను సృష్టిస్తాయి.

MVP vs MVVM

MVVM రేఖాచిత్రం

MVP మరియు MVVM ల మధ్య ఉన్న ప్రధాన తేడాలు ఏమిటంటే, MVP లో ప్రెజెంటర్ ఇంటర్‌ఫేస్‌లు వీక్షణతో మరియు MVVM లో వీక్షణ డేటా మరియు ఈవెంట్ మార్పులపై కేంద్రీకృతమై ఉంది.

MVP లో మేము ప్రెజెంటర్ మరియు ఇంటర్‌ఫేస్‌లు / ప్రోటోకాల్‌లను ఉపయోగించి వీక్షణ మధ్య మాన్యువల్ లింక్‌ను సృష్టిస్తాము. MVVM లో మేము RxSwift, KVO తో ఆటోమేటిక్ డేటా బైండింగ్ లేదా జెనెరిక్స్ మరియు మూసివేతలతో కూడిన యంత్రాంగాన్ని నిర్వహిస్తాము.

MVVM లో వీక్షణ మోడల్ మరియు వ్యూ మధ్య ఒప్పందం (ఉదా. జావా ఇంటర్ఫేస్ / iOS ప్రోటోకాల్) కూడా మాకు అవసరం లేదు, ఎందుకంటే మేము సాధారణంగా అబ్జర్వర్ డిజైన్ సరళి ద్వారా కమ్యూనికేట్ చేస్తాము.

MVP ప్రతినిధి నమూనాను ఉపయోగిస్తుంది ఎందుకంటే ప్రెజెంటర్ లేయర్ వీక్షణ లేయర్‌కు ఆదేశాలను అప్పగిస్తుంది. అందువల్ల, అతను కేవలం ఇంటర్ఫేస్ / ప్రోటోకాల్ సంతకం అయినా, వీక్షణ గురించి కొంత తెలుసుకోవాలి. నోటిఫికేషన్ సెంటర్ మరియు టేబుల్ వ్యూ ప్రతినిధుల మధ్య వ్యత్యాసం గురించి ఆలోచించండి. కమ్యూనికేషన్ ఛానెల్ సృష్టించడానికి నోటిఫికేషన్ కేంద్రానికి ఎటువంటి ఇంటర్‌ఫేస్‌లు అవసరం లేదు. అయితే, టేబుల్ వ్యూ ప్రతినిధులు తరగతులు అమలు చేయవలసిన ప్రోటోకాల్‌ను ఉపయోగిస్తారు.

ఛార్జ్ సూచిక యొక్క ప్రదర్శన తర్కం గురించి ఆలోచించండి. MVP లో, ప్రెజెంటర్ ViewProtocol.showLoadingIndicator ను నడుపుతుంది. MVVM లో, వ్యూమోడల్‌లో ఐలోడింగ్ ఆస్తి ఉండవచ్చు. ఈ ఆస్తి మారినప్పుడు మరియు అప్‌డేట్ అయినప్పుడు వ్యూ లేయర్ ఆటోమేటిక్ డేటా బైండింగ్ ద్వారా గుర్తిస్తుంది. MVP MVVM కన్నా ఎక్కువ బలవంతంగా ఉంటుంది ఎందుకంటే ప్రెజెంటర్ ఆదేశాలను జారీ చేస్తుంది.

ప్రత్యక్ష ఆర్డర్‌ల కంటే డేటా మార్పుల గురించి MVVM ఎక్కువ, మరియు మేము నవీకరణలను వీక్షించడానికి డేటా మార్పులను లింక్ చేస్తాము. మేము MVVM తో పాటు RxSwift మరియు ఫంక్షనల్ రియాక్టివ్ ప్రోగ్రామింగ్ నమూనాను ఉపయోగించినప్పుడు, మేము కోడ్‌ను మరింత బలవంతం మరియు మరింత డిక్లరేటివ్‌గా చేసాము.

MVVM MVP కంటే పరీక్షించడం సులభం, ఎందుకంటే MVVM అబ్జర్వర్ డిజైన్ సరళిని ఉపయోగిస్తుంది, ఇది భాగాల మధ్య డేటాను విడదీసిన పద్ధతిలో బదిలీ చేస్తుంది. కాబట్టి వీక్షణ మరియు ప్రెజెంటర్ మధ్య కమ్యూనికేషన్‌ను పరీక్షించడానికి పద్ధతి కాల్‌లను అపహాస్యం చేయకుండా, రెండు వస్తువులను పోల్చడం ద్వారా డేటాలోని మార్పులను చూడటం ద్వారా మనం పరీక్షించవచ్చు.

PS: ఐటెమ్ గురించి నేను కొన్ని అప్‌డేట్స్ చేసాను, అది చాలా పెరుగుతుంది. అందువల్ల దీనిని మూడు భాగాలుగా విభజించడం అవసరం. మీరు మూడవ భాగాన్ని ఇక్కడ చదవవచ్చు.

రెండవ భాగం ఇక్కడ ముగుస్తుంది. అన్ని అభిప్రాయాలు స్వాగతం. మూడవ భాగం VIPER, VIP, రియాక్టివ్ ప్రోగ్రామింగ్, ట్రేడ్-ఆఫ్స్, అడ్డంకులు మరియు కాంటెక్చువల్ సెన్స్ గురించి.

చదివినందుకు ధన్యవాదములు! మీరు ఈ కథనాన్ని ఆస్వాదించినట్లయితే, దయచేసి చప్పట్లు కొట్టండి కాబట్టి ఇతరులు కూడా చదవగలరు :)