कोरडाटा मॉडल डिज़ाइन: क्या NSFetchRequest का अत्यधिक उपयोग खराब डिजाइन किए गए मॉडल का एक लक्षण है?

Question

कोर डेटा ऑब्जेक्ट्स को NSFetchRequest या ग्राफ में अन्य ऑब्जेक्ट्स के साथ रिश्तों का पालन करके पुनर्प्राप्त किया जा सकता है। क्या यह कहना उचित है कि एक अच्छी तरह से डिज़ाइन किए गए मॉडल में पर्याप्त रिश्तों (और प्राप्त संपत्तियां) होंगी, जैसे NSFetchRequests का उपयोग न्यूनतम रखा जाता है?

काउंटर तर्क यह है कि आईओएस में NSFetchedRequestController मौजूद है। संभवतः अगर ऐप्पल का मानना ​​था कि संबंधों और प्राप्त संपत्तियों ने मौजूदा दोष/कैशिंग के साथ संतोषजनक प्रदर्शन प्रदान किया है तो वे NSFetchedRequestController नहीं बनाएंगे।

उदाहरण हैं जब NSFetchRequest का उपयोग करते समय कोर डेटा SQLite के भीतर सभी काम कर सकते हैं। एक उदाहरण कुल मूल्य लाएगा।

इस पर कोई विचार? मैंने Core Data Programming Guide पर एक नज़र डाली है। 'प्रबंधित करने वाले ऑब्जेक्ट्स' और 'कोर डेटा प्रदर्शन' अनुभागों में प्रासंगिक सलाह है, लेकिन अनुरोधों को प्राप्त करने या इसके विपरीत संबंधों को दृढ़ता से सुझाव देने के लिए कुछ भी नहीं है।

Answer 1

अंगूठे का सामान्य नियम यह है कि डेटा मॉडल जितना सरल होता है उतना आसान डेटा मॉडल बेहतर संबंध काम करता है।

उदाहरण के लिए, यदि आपके डेटा मॉडल में कोई रिश्ते वाला एक इकाई नहीं है तो एक fetch अलग प्रबंधित वस्तुओं को खोजने के लिए सबसे अच्छा काम करेगा। यदि आपके पास दो दर्जन से अधिक रिश्ते वाले दर्जन इकाइयों के साथ डेटा मॉडल है, तो आप रिश्ते का भारी उपयोग करेंगे।

Answer 2

मैं कहूंगा कि संबंधों और NSFetchRequest प्रत्येक में उनकी ताकत और कमजोरियां होती हैं। एक डेवलपर के रूप में आपको पता होना चाहिए कि यह कब एक या दूसरे का उपयोग करना उचित है। उदाहरण के लिए इस मॉडल ले:

-------------- 1   * ------------ 
| Department |<------------->>| Employee | 
--------------    ------------ 
| name  |    | name  | 
--------------    | age  | 
           | salary | 
           ------------ 

आप सभी के लिए एक विशेष विभाग से संबंधित कर्मचारियों को पुनः प्राप्त करना चाहते हैं तो यह संबंध पालन करने के लिए 'department.employees' उचित है। कर्मचारी इकाई के लिए एनएसएफएटीएचआरक्वेट बनाने के लिए उचित नहीं है 'विभाग == xxxx'।

इसके विपरीत, यदि आप किसी विशेष विभाग के लिए वेतन> x के साथ कर्मचारियों को ढूंढना चाहते हैं तो एक्सएसएटीएचआरक्वेट का उपयोग 'विभाग == xxxxx और वेतन> एक्स' जैसे भविष्यवाणी के साथ करना उचित है। विभाग का उपयोग कर सभी कर्मचारियों को पुनर्प्राप्त करना उचित नहीं है। कर्मचारियों के रिश्ते और फिर उच्च कमाई करने के लिए उन्हें एक लूप में फिर से भरना।

संक्षेप में, संबंध या NSFetchRequests स्वाभाविक रूप से 'अच्छा' या 'बुरा' नहीं हैं। बस उन्हें उचित रूप से उपयोग करें। अपने ऑब्जेक्ट ग्राफ नेविगेट करने के लिए रिश्तों का उपयोग करें। सबसेट खोज करने के लिए NSFetchRequest का उपयोग करें या जहां आपको परिणामों के रूप में लौटने वाले परिणामों की लचीलापन की आवश्यकता है या एनएसईएक्सप्रेस का उपयोग करने की आवश्यकता है।

संपादित करें जोड़ने के लिए:

अपने कोड भर अटे पड़े NSFetchRequests का एक बहुत बुरा डिजाइन का एक संकेत है। मैं हमेशा कस्टम NSManagedObject कक्षाओं में डेटा अनुरोधों को समाहित करता हूं और नियंत्रक कोड को देखने/देखने में कोई भी कोर डेटा कॉल न करने का प्रयास करता हूं।

प्राप्ति गुण, एक ही चीज़ को प्राप्त करने का एक तरीका है, मुझे लगता है। मैं इसे करने के लिए कोर डेटा संपादक का उपयोग करने के बजाय कोड में NSFetchRequest बनाना पसंद करता हूं। यह बहुत अधिक लचीला है लेकिन दोनों तरीकों से वास्तव में एक ही चीज़ की मात्रा है।

Answer 3

जब आप कोर्डटा में एक मॉडल तैयार करते हैं तो आपको यह ध्यान रखना चाहिए कि यदि आपके पास मोड में 1, 2 या n संबंध हैं, तो यह इंगित करता है कि आपका ऑब्जेक्ट ग्राफ़ SQL डेटाबेस के रूप में व्यवहार करेगा क्योंकि यह केवल मुख्य प्राप्त करेगा पंक्तियों, आपके ऐप को छोड़कर सभी ऑब्जेक्ट्स के पहले अनुरोध में स्पष्ट आवश्यकता है। असल में ऐप्पल आपके मॉडल को प्रदर्शन कारणों से संबंधों में विभाजित करने के लिए प्रोत्साहित करता है, इसलिए जब उस पल में आपके मॉडल की गलती पर आपके मॉडल की गलती बाकी को लाएगी। एकमात्र पहलू आपको इसके हटाए गए नियमों (शून्य, कैस्केड ..) के बारे में परवाह करना चाहिए क्योंकि खराब डिज़ाइन हटाया गया नियम क्रैश या प्रदर्शन को प्रभावित कर सकता है। मेरा विश्वास करो, मैंने कभी भी कोर डेटा के रूप में इतना कुशल नहीं देखा है। एक मजबूत मॉडल बनाएं और कोर डेटा बाकी कर देगा।

मेरी क्षुधा (Mariette) में से एक का उपयोग कोर डेटा और एक अन्य (billingfiles) एसक्यूएल का उपयोग