12

मैं यह पता लगाने की कोशिश कर रहा हूं कि एक डोमेन संचालित डिजाइन प्रोजेक्ट में कैशिंग (डालने/निकालने) के लिए कौन सी परत जिम्मेदार होनी चाहिए। लक्ष्य भंडार से पुनर्प्राप्त किसी भी संस्था को कैश करके वेब अनुप्रयोग के प्रदर्शन में सुधार करना है।एक भंडार, डोमेन या अनुप्रयोग की चिंता कैशिंग है?

MyApp.Infrastracture 
MyApp.Repositories 
MyApp.Domain 
MyApp.WebApplication 

मुझे लगता है कि क्योंकि यह केवल वेब अनुप्रयोग है कि तब कैश का इस्तेमाल करता है, यह इस परत कि कैशिंग तर्क जाना चाहिए किया जाना चाहिए:

मेरे समाधान के रूप में निम्नानुसार अलग किया जाता है? हालांकि यह सही नहीं लगता है क्योंकि मैं वेब ऐप हल्के वजन रखना चाहता हूं और वेब पृष्ठों की सेवा पर केंद्रित हूं।

इसके अलावा कैशिंग एक प्रथम श्रेणी डोमेन अवधारणा नहीं है, इसलिए डोमेन परत में प्राकृतिक फिट नहीं है।

क्या करना है?

+4

यह उपर्युक्त सभी की चिंता है। कैशिंग उन क्रॉस कटिंग चिंताओं में से एक है जिसे प्रत्येक परत को व्यक्तिगत रूप से संभालने की आवश्यकता होती है और एप्लिकेशन को ऑर्केस्ट्रेट करने की आवश्यकता होती है। – Oded

+0

@ ओडेड - आपको उस टिप्पणी को एक उत्तर देना चाहिए –

+1

@ डेविड केम्प - किया गया ... – Oded

उत्तर

11

यह उपर्युक्त सभी की चिंता है।

कैशिंग उन क्रॉस कटिंग चिंताओं में से एक है जिसे प्रत्येक परत को व्यक्तिगत रूप से संभालने की आवश्यकता होती है और एप्लिकेशन को ऑर्केस्ट्रेट करने की आवश्यकता होती है।

+1

धन्यवाद, मुझे लगता है कि वेब अनुप्रयोग ऑर्केस्ट्रेटर का उल्लेख करते समय आपने मुझे इसके लिए नाखुश किया। – Fixer

4

मैं पूरी तरह से Oded से सहमत हूं कि यह एक क्रॉस काटने की चिंता है, लेकिन यह कैश किए गए आइटम के ग्राहक के लिए भी पारदर्शी होना चाहिए।

उदाहरण के लिए, आपके भंडार के उपयोगकर्ताओं को यह परवाह नहीं करना चाहिए कि कोई आइटम कैश किया गया है या नहीं।

मैं तर्क दूंगा कि यदि आपके समाधान का कैशिंग एक महत्वपूर्ण पहलू है तो इसे डोमेन में स्पष्ट किया जाना चाहिए, हालांकि, आपको शायद यह पता चलेगा कि यह वास्तव में बुनियादी ढांचे के हिस्से के रूप में समाप्त होता है और इसे (चुपचाप) के माध्यम से वितरित किया जाता है जो भी आईओसी कंटेनर आप उपयोग करते हैं।

0

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

5

आप

विख्यात लक्ष्य किसी भी संस्थाओं है कि भंडार से लिया गया है कैशिंग द्वारा वेब अनुप्रयोग के प्रदर्शन में सुधार करने के लिए है।

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

जैसा कि @ ओडेड ने इंगित किया है, कैशिंग वास्तव में कहीं भी हो सकती है, और यदि आप प्रदर्शन एक समस्या है, तो आप शायद इसे कई जगहों पर कार्यान्वित कर पाएंगे, और प्रत्येक स्थान इसे अलग-अलग कर सकता है। उदाहरण के लिए, आप अपने डोमेन में कुछ प्रश्नों के परिणाम कैश कर सकते हैं, या आप पूरे HTML प्रतिक्रियाओं को कैश कर सकते हैं।

क्रॉस-लेयर समन्वय आता है क्योंकि कैश काफी कमजोर अमूर्त हो सकता है। यदि आपकी डोमेन ऑब्जेक्ट्स कैश की जाती हैं, तो उन्हें कब बेकार किया जाना चाहिए? क्या होगा यदि एक धागा कैश्ड ऑब्जेक्ट का उपयोग कर रहा है और दूसरा नहीं है? क्या होगा यदि आप क्वेरी परिणाम कैश कर रहे हैं, लेकिन अंतर्निहित वस्तुओं को तब से बदल दिया है? बुनियादीकरण परिप्रेक्ष्य और व्यावसायिक परिप्रेक्ष्य दोनों से, अवैध और कब अवैध करना है, कठिन प्रश्न हैं। बालों के प्रश्न हमेशा खराब नहीं होते हैं।