वेब सेवाओं के साथ कोर डेटा अनुशंसित पैटर्न?

Question

मैं आईओएस के लिए एक ऐप लिख रहा हूं जो वेब सेवा द्वारा प्रदान किए गए डेटा का उपयोग करता है। मैं स्थानीय भंडारण और डेटा की दृढ़ता के लिए कोर डेटा का उपयोग कर रहा हूं, ताकि वेब के पहुंच के योग्य होने पर डेटा का कुछ मूल सेट उपयोगकर्ता के लिए उपलब्ध हो।

इस ऐप के निर्माण में, मैं कोर डेटा के बारे में बहुत सी पोस्ट पढ़ रहा हूं। ऐसा करने के मैकेनिक्स पर वहां बहुत कुछ लगता है, मैंने इसके लिए सामान्य सिद्धांतों/पैटर्न पर कम देखा है।

मुझे आश्चर्य है कि एक अनुशंसित बातचीत मॉडल के लिए वहां कुछ अच्छे संदर्भ हैं या नहीं।

उदाहरण के लिए, उपयोगकर्ता ऐप पर नई ऑब्जेक्ट्स बनाने में सक्षम होंगे। आइए कहें कि उपयोगकर्ता एक नया कर्मचारी ऑब्जेक्ट बनाता है, उपयोगकर्ता आम तौर पर इसे बना देगा, इसे अपडेट करेगा और फिर इसे सेव करेगा। मैंने उन सिफारिशों को देखा है जो सर्वर में इन चरणों में से प्रत्येक को अद्यतन करते हैं -> जब उपयोगकर्ता इसे बनाता है, जब उपयोगकर्ता फ़ील्ड में परिवर्तन करता है। और यदि उपयोगकर्ता अंत में रद्द हो जाता है, तो सर्वर पर एक डिलीट भेजा जाता है। एक ही ऑपरेशन के लिए एक और अलग सिफारिश स्थानीय स्तर पर सबकुछ रखना है, और जब उपयोगकर्ता बचाता है तो केवल सर्वर को पूरा अपडेट भेजता है।

यह उदाहरण एक तरफ है, अगर मैं सीआरयूडी संचालन को संभालने के तरीके पर कुछ सामान्य सिफारिशें/पैटर्न हैं और यह सुनिश्चित करता हूं कि वे वेबसर्वर और कोर्डटा के बीच सिंक हो जाएं तो मुझे उत्सुकता है।

बहुत धन्यवाद।

Answer 1

आप 'लेन-देन' के बारे में पढ़ना चाहेंगे - जो मूल रूप से एक ही परमाणु क्रिया/परिवर्तन के रूप में कई क्रियाओं/परिवर्तनों का समूह है। यह आंशिक बचत से बचने में मदद करता है जिसके परिणामस्वरूप सर्वर पर असंगत डेटा हो सकता है।

आखिरकार, यह एक बहुत बड़ा विषय है - खासकर यदि सर्वर डेटा एकाधिक ग्राहकों में साझा किया जाता है। सबसे सरल, आप मूल नीतियों पर निर्णय लेना चाहते हैं। क्या आखिरी जीत जीतती है? सर्वर डेटा स्टोर में वस्तुओं पर दूरस्थ रूप से आयोजित ताले की कुछ धारणा है? संघर्ष कैसे हल किया जाता है, जब दो ग्राहक एक ही वस्तु की एक ही संपत्ति को संपादित करते हैं, कहते हैं?

आईफोन पर चीजें कैसे की जाती हैं, इस संबंध में मैं इस बात से सहमत हूं कि "पूर्ण" सर्वर (अलग थ्रेड में) में लगातार परिवर्तन के लिए एक प्राकृतिक बिंदु प्रदान करता है।

Answer 2

मुझे लगता है कि आपके द्वारा उल्लेख किए गए मामले में सबसे अच्छा तरीका केवल स्थानीय स्तर पर डेटा स्टोर करना है जब तक कि उपयोगकर्ता नए रिकॉर्ड को जोड़ने के बिंदु तक नहीं पहुंचता। सर्वर पर प्रत्येक फ़ील्ड को संपादित करना कुछ हद तक अत्यधिक है।

आईफोन ऐप्स का एक सामान्य मुहावरे यह है कि "सहेजें" जैसी कोई चीज़ नहीं है। आम तौर पर उपयोगकर्ता कुछ समझदार बिंदुओं पर चीजों को करने की अपेक्षा करेगा, लेकिन यह उपयोगकर्ता को प्रति बचत के रूप में प्रस्तुत नहीं किया जाता है।

तो, उदाहरण के लिए, कल्पना करें कि आपके पास एक यूआई है जो उपयोगकर्ता को कुछ प्रकार के रिकॉर्ड को संपादित करने देती है जो स्थानीय कोर डेटा में सहेजी जाएगी और सर्वर पर भी भेजी जाएगी। बिंदु पर उपयोगकर्ता एक नया रिकॉर्ड बनाने के लिए यूआई से बाहर निकलता है, तो शायद वे "होन" नामक एक बटन दबाएंगे (एनबी जिसे आमतौर पर "सेव" नहीं कहा जाता है)। बिंदु पर उन्होंने "पूर्ण" मारा, आप कोर डेटा लिखना बंद करना चाहते हैं और दूरस्थ सर्वर पर भी धक्का शुरू करना चाहते हैं। सर्वर पुस एच को यूआई को हॉग नहीं करना होगा या इसे पूरा होने तक इंतजार करना होगा - यह ऐप का उपयोग जारी रखने की अनुमति देने के लिए अच्छा है - लेकिन यह हो रहा है। यदि सर्वर पर अद्यतन पुश विफल हो गया है, तो आप इसे उपयोगकर्ता को सिग्नल करना चाहते हैं या कुछ उचित कर सकते हैं।

कोर डेटा और/या रिमोट सर्वर पर लिखने की ग्रैन्युलरिटी की योजना बनाते समय खुद से पूछने का एक अच्छा सवाल यह है: यदि ऐप क्रैश हो जाता है, या फोन किसी भी विशेष स्थान पर बिजली से बाहर हो जाता है तो क्या होगा एप्लिकेशन? डेटा का कितना नुकसान संभवतः हो सकता है? अच्छे ऐप्स डेटा हानि के जोखिम को कम करते हैं और किसी भी कारण से बाहर निकलने के बाद पहले के समान स्थिति में फिर से लॉन्च कर सकते हैं।

Answer 3

अपने बालों को थोड़ा फाड़ने के लिए तैयार रहें। मैं इस पर काम कर रहा हूं, और समस्या यह है कि कोर डेटा नमूने काफी सरल हैं। जिस मिनट आप एक जटिल मॉडल में जाते हैं और आप NSFetchedResultsController और उसके प्रतिनिधि का उपयोग करने का प्रयास करते हैं, तो आप कई संदर्भों का उपयोग करने के साथ सभी प्रकार की समस्याओं में टक्कर डालते हैं।

मैं पृष्ठभूमि में "ब्लॉक" में अपने webservice से डेटा को पॉप्युलेट करने के लिए एक का उपयोग करता हूं, और तालिकादृश्य के लिए दूसरा स्थान उपयोग करने के लिए - आप मास्टर सूची और एक विस्तृत दृश्य के लिए तालिकादृश्य का उपयोग कर अंततः समाप्त हो जाएंगे।

कोको में ब्लॉक का उपयोग करने पर ब्रश करें यदि आप किसी सर्वर से डेटा प्राप्त करने या भेजने के दौरान अपने ऐप को उत्तरदायी रखना चाहते हैं।