मुझे यकीन नहीं है कि मुझे अपने भंडार पैटर्न में कैशिंग को कार्यान्वित करना चाहिए।रिपोजिटरी पैटर्न - कैशिंग
क्या मुझे इसे सेवा-तर्क या भंडार में लागू करना चाहिए?
जीयूआई -> BusinessLogic (सेवा) -> DataAccess (डेटा संग्रह स्थान)
मैं भंडार/डेटा का उपयोग परत में इसे संभाल होगा। तर्क यह है कि यह डेटा परत कहां से प्राप्त करने के लिए व्यापार परत पर निर्भर नहीं है, यह भंडार का काम है। भंडार तब तय करेगा कि डेटा एक्सेस लॉजिक की परिस्थितियों के आधार पर कैश (यदि यह बहुत पुराना नहीं है) या लाइव डेटा स्रोत से डेटा प्राप्त करना है।
यह एक व्यापार तर्क समस्या से अधिक डेटा पहुंच चिंता है।
यह एक अच्छा विचार है कि कैशिंग तर्क सीधे अपने भंडार में न डालें, क्योंकि यह एकल उत्तरदायित्व सिद्धांत (एसआरपी) और चिंता का पृथक्करण करता है। एसआरपी अनिवार्य रूप से कहता है कि आपके वर्गों में केवल बदलने का एक कारण होना चाहिए। यदि आप एक ही कक्षा में डेटा एक्सेस और कैशिंग पॉलिसी की चिंताओं को स्वीकार करते हैं, तो यदि इनमें से किसी एक को बदलने की जरूरत है तो आपको कक्षा को छूने की आवश्यकता होगी। आपको शायद यह भी पता चलेगा कि आप डीआरवाई सिद्धांत का उल्लंघन कर रहे हैं, क्योंकि कई अलग-अलग भंडार विधियों में कैशिंग तर्क फैलाना आसान है, और यदि इसमें से किसी को बदलने की जरूरत है, तो आप कई विधियों को बदलना चाहते हैं।
बेहतर तरीका कैचिंग तर्क को एक अलग प्रकार में लागू करने के लिए प्रॉक्सी या रणनीति पैटर्न का उपयोग करना है, उदाहरण के लिए एक कैशड रिपोजिटरी, जो तब कैश खाली होने पर आवश्यक वास्तविक डीबी-केंद्रित भंडार का उपयोग करती है। मैं दो लेख जो प्रदर्शित कैसे इस का उपयोग कर नेट/सी #, जो आप अपने ब्लॉग पर मिलेगा लागू करने के लिए, यहाँ लिखा है:
आप वीडियो पसंद करते हैं, मैं भी Pluralsight पर प्रॉक्सी डिजाइन पैटर्न में पैटर्न का वर्णन है, यहाँ:
उत्तर के लिए धन्यवाद! मुझे लगता है कि यह आलसी लोडिंग कार्यान्वयन के लिए भी बेहतर है। – Beni