स्विफ्टमधील डेटा स्त्रोत ... किंवा आपल्या अ‍ॅपचे आर्किटेक्चर निश्चित करणार्‍या या नवीन ट्रेंडी चिकाटीची चौकट कशी टाळायची

ही एंट्री मूलतः dcordo.me मध्ये प्रकाशित केली गेली. आपणास येथे सदैव अधिक वर्तमान आवृत्ती आढळेल.

IOS च्या जगात आमच्या डेटाच्या दृढतेस सामोरे जाण्यासाठी खरोखर चांगल्या फ्रेमवर्क अटी आहेत.

उदाहरणार्थ, कोर डेटा हा Appleपलचा एक चांगला उपाय आहे जो अगदी मोठ्या प्रमाणात डेटासह देखील आश्चर्यकारक प्रदर्शन करतो. पण इतरही काही पर्याय आहेत. या पर्यायांपैकी एक म्हणजे क्षेत्र म्हणजे एक सोपी वाक्यरचना असलेल्या कोर डेटापेक्षा अधिक चांगली कामगिरी देऊ शकेल.

दुर्दैवाने, या चिकाटीच्या जगात, सर्व काही अपेक्षेइतके आश्चर्यकारक नाही. तसेच बर्‍याच समस्या आहेत. मला कोअर डेटा, क्षेत्र किंवा इतर बर्‍याच ट्रेंडी पर्सिस्टंट फ्रेमवर्क सह खरोखरच वाईट अनुभव आले आहेत, केवळ फ्रेमवर्कमुळेच नाही, तर प्रकल्पांमध्ये लागू होण्याच्या पद्धतीमुळे देखील.

मुख्य समस्या अशी आहे की त्यांनी सोडवलेल्या समस्येच्या जटिलतेमुळे, या चौकटींमध्ये बर्‍यापैकी जटिल वाक्यरचना असते. आणि जर फ्रेमवर्कची व्याप्ती स्पष्टपणे परिभाषित केली गेली नसेल तर, ऑब्जेक्ट्स शेवटी संपूर्ण प्रकल्पात वितरीत केले जातात जेणेकरुन यूआयव्ही व्यू एनएस मॅनेजड ऑब्जेक्ट्स, यूआयसीकलेक्शन व्ह्यूज व आरएलएमओब्जेक्ट्ससह सेल भरतील.

असे कधीही होऊ नये, अॅपची चिकाटी ही काहीतरी फारच अंतर्गत असावी, आमच्या अ‍ॅपच्या मुख्य भागाच्या सखोल पातळीत लपलेली आणि आपल्या UI लेव्हलशी संबंधित नाही. आणि सर्वात महत्वाची गोष्ट अशी आहे की भविष्यात भिन्न निराकरण किंवा चौकट वापरण्यासाठी कोडच्या या सर्व भागाची पुनर्स्थित करणे खूप सोपे असले पाहिजे.

हे युटोपियासारखे वाटते, नाही का? पण ... आम्ही ते कसे मिळवू शकतो? मूलभूतपणे, आम्हाला केवळ एक अमूर्त समाधान आवश्यक आहे जो आमच्या डेटाच्या चिकाटीशी सामना करण्यासाठी इंटरफेस परिभाषित करतो. माझा अर्थ डेटा स्रोतांसह आहे.

टीप: कृपया काही टेबलव्यूज, कलेक्शनव्ह्यूज इ. विकसित करण्यासाठी आयओएस द्वारे वापरलेल्या डेटा स्रोतांच्या या संकल्पनेचा गोंधळ करू नका.

डेटा स्रोत

डेटा स्रोत कोर व्यवसायाच्या तार्किकतेपासून टिकून राहण्याचे तर्कशास्त्र दूर करतात आणि फ्रेमवर्कच्या विशिष्ट तपशीलाकडे दुर्लक्ष करून डेटामध्ये प्रवेश करण्याची परवानगी देतात.

आम्ही स्विफ्टमध्ये अगदी सोप्या प्रोटोकॉलचा वापर करून आमचे डेटा स्रोत व्यवस्थापित करण्यासाठी एक इंटरफेस तयार करू शकतो जो संपूर्ण सीआरयूडी (तयार करा रीड अपडेट हटवा) इंटरफेस प्रदान करतो.

पण काय आहे हा टी?

बरं, हा टी आपण कायम राहण्याची किंवा आपल्या चिकाटीच्या चौकटीतून पुनर्प्राप्त करण्याची अपेक्षा करतो. परंतु आमचा अर्थ असा आहे की आम्ही अपेक्षा करतो, फ्रेमवर्क अपेक्षित ऑब्जेक्ट नाही. या प्रकारच्या वस्तू सामान्यत: अस्तित्व म्हणून ओळखल्या जातात आणि सामान्यत: साध्या वस्तू असतात (संबंधित लॉजिक नसलेल्या वस्तू).

मुळात, हा टी एनएस मॅनेजड ऑब्जेक्ट, आरएलएमओब्जेक्ट, आर्काइव्ह इत्यादी असू नये.

चला उदाहरणासह अनुसरण करूया. Amazonमेझॉनद्वारे आमच्यात भरती झाल्याची कल्पना करा आणि पुस्तकांच्या यादी त्यांच्या कॅटलॉगमध्ये ठेवायला सांगितले. (सोपे कार्य )

आमच्या पुस्तक अस्तित्व असू शकते:

मी म्हटल्याप्रमाणे, त्यात दृढता फ्रेमवर्कशी संबंधित काहीही नसते, फक्त आम्हाला ठेवायची माहिती. तेव्हा आम्ही हा डेटा कसा जतन करू? उदाहरणार्थ उदाहरणार्थ क्षेत्र वापरू.

आम्ही रिअलसाठी आधी परिभाषित केलेल्या प्रोटोकॉलची अंमलबजावणी सुरू करू शकतो. येथे आम्ही दायराच्या विशिष्ट अंमलबजावणीच्या तपशीलांसह प्रारंभ करू शकतो:

पण थांब, आपण ते पाहिले? मी येथे फसवणूक करतो, जरी दिलेला इंटरफेस ऑब्जेक्ट "बुक" बरोबर एकत्र काम करत असला तरी तो आंतरिकरित्या दुसर्या ऑब्जेक्टला संग्रहित करतो आणि पुनर्प्राप्त करतो, तो ... "रियलमबुक" आहे.

मग या "रियलमबुक" (आणि "रिअलमॉथॉरिफर", जसे आपण पाहू शकाल) काय आहेत?

मुळात, हे आमच्या घटकांच्या 1: 1 मॅपिंग ऑब्जेक्ट्स आहेत. तथापि, मुख्य फरक असा आहे की आमच्या फ्रेमवर्कची सर्व "गलिच्छ" विशिष्ट तपशील असू शकतात जी आम्हाला आमच्या अ‍ॅपमध्ये पसरवायची नाहीत. हे आमचे एनएस मॅनेजड ऑब्जेक्ट्स आहेत किंवा रिअलमोब्जेक्ट्सच्या बाबतीत (वर्ग असणे भाग पडले आहे, "ऑब्जेक्ट" चा वारसा असणे आवश्यक आहे, अ‍ॅरेऐवजी सूची वापरण्यास भाग पाडणे इ.). आम्ही या सर्व गोष्टी आमच्या रियलबूक ऑब्जेक्टमध्ये लपवू शकतो.

आणि उर्वरित अ‍ॅपमधून, अंतर्गत अंमलबजावणी किती स्थिर आहे याची पर्वा न करता आम्ही केवळ आमच्या घटकांचा वापर करून डेटासोर्स प्रोटोकॉलसह कार्य करू शकतो. फक्त म्हणून जादू ...

आणि फक्त अस्वीकरण म्हणून, मी हे उदाहरण सोपा ठेवू इच्छितो, परंतु आपण हे `BooksRealmDataSource` ऐकले आहे? नाही? हे खरोखर जेनेरिकसाठी ओरडत आहे, नाही का?

रिपॉझिटरी पॅटर्न

आता आपल्याला फ्रेमवर्कची चिंता करण्याची गरज नाही. आपल्या अ‍ॅपचे सर्व डेटा स्रोत मागील प्रोटोकॉलची अंमलबजावणी करतात त्या परिस्थितीची कल्पना करा.

म्हणजे, मी नेहमीच त्याच प्रकारे माहितीमध्ये प्रवेश करू शकतो, ती कुठूनही आली तरीही. हार्ड ड्राइव्ह, मेमरी किंवा अगदी नेटवर्क. ते सर्व एकाच प्रोटोकॉलमधून आले आहेत.

वेगळ्या डेटा स्त्रोतांमधून पुनरावृत्ती होणार्‍या वेगवान किंवा सर्वात योग्य स्त्रोतांमधून डेटा पुनर्प्राप्त करणारा एक रेपॉजिटरी नमुना तयार करणे खूप सोपे होईल.

आमची भांडारांची अंमलबजावणी करताना जनरेशनची पुन्हा विनंती केली जाते. आपल्याला केवळ व्यवस्थापित करण्यासाठी डेटा स्रोतांची यादी आणि त्यांच्या अनुप्रयोगासाठी एक धोरण मिळेल.

उदाहरणार्थ, मागील पुस्तकात आमच्या पुस्तकांची यादी मिळविण्यासाठी एका संग्रहात तीन भिन्न डेटा स्रोत असू शकतात: स्टोरेज, डिस्क आणि नेटवर्क. पहिल्या गेमच्या रणनीतीसह.

तथापि, आम्ही नेहमी लॉग इनची माहिती आमच्या बॅकएंडसह तपासतो हे सुनिश्चित करण्यासाठी वापरकर्ता लॉग इन करणार्‍या रिपॉझिटरीमध्ये फक्त एक डेटा स्रोत (नेटवर्क) असते.

शेवटी, आमच्या उर्वरित अ‍ॅपसाठी, याचा अर्थ डेटा कोठून आला आहे किंवा कोणत्या फ्रेमवर्क अंतर्गत वापरले जातात याची पर्वा न करता जादू म्हणून डेटा पुनर्प्राप्त करणे होय. नेमका आम्हाला डेटा हवा असतो.

आणि मी म्हटल्याप्रमाणे, त्याबद्दल सर्वात चांगली गोष्ट म्हणजे आम्हाला या पद्धतीवर आधारित एक प्रचंड मॉड्यूलरिटी प्राप्त झाली आहे आणि जेव्हा आम्हाला पाहिजे तेव्हा आपली आंतरिक अंमलबजावणी अगदी सहजपणे बदलू शकते. आपण एक्स नवीन ट्रेंडी फ्रेमवर्क वापरुन पाहू इच्छिता? आपल्या डेटा स्रोतांपैकी एकाची अंमलबजावणी फक्त बदला आणि उर्वरित अ‍ॅपला कोणत्याही बदलाची आवश्यकता नाही.

जर आपल्याकडे काही प्रश्न असतील तर मला गीथब, ट्विटर किंवा डीसीओर्डो.मी वर मोकळे करा.