हम एंटिटी फ्रेमवर्क (आरआईए सेवाओं के साथ सिल्वरलाइट सटीक होने के लिए) का उपयोग कर एक डब्ल्यूपीएफ एप्लीकेशन लिख रहे हैं। हम एप्लिकेशन के माध्यम से एक साझा ऑब्जेक्ट कॉन्टेक्स्ट का उपयोग कर रहे हैं ताकि हम मॉड्यूल में डेटा साझा करने से लाभ उठा सकें।विंडोज़/डब्ल्यूपीएफ/सिल्वरलाइट एप्लिकेशन में एंटीटी फ्रेमवर्क ऑब्जेक्ट कॉन्टेक्स्ट
समस्या यह है कि - यदि उपयोगकर्ता अपने काम के दौरान खुलता है तो हम ऐतिहासिक बिक्री कहें, यह ऑब्जेक्ट कॉन्टेक्स्ट में लोड हो जाता है और एप्लिकेशन के अंत तक वहां रहता है। तो एक और पैटर्न का इस्तेमाल किया जाना चाहिए।
मुझे पता है कि ऑब्जेक्ट कॉन्टैक्स का उपयोग एकल इकाई-कार्य के रूप में किया जाना चाहिए। लेकिन फिर, आप एप्लिकेशन के अन्य हिस्सों को कैसे जानते हैं कि कुछ बदल गया है और उन्हें अपना डेटा फिर से लोड करना चाहिए?
संपादित करें: ठीक है, EventAggregator, लेकिन फिर, इससे अन्य सभी हिस्सों को उनके (शायद अधिकतर डुप्लिकेट) डेटा को फिर से लोड करने का कारण बन जाएगा। इसके अलावा सभी प्रकार के entites समूहों के लिए शायद कई घटनाओं की आवश्यकता होगी।
आप इन समस्याओं का समाधान कैसे करते हैं? मेरा वर्तमान समाधान एक प्रकार का समझौता है - पूरे एप्लाइक्शन द्वारा उपयोग किए जाने वाले मूल डेटा के लिए साझा ऑब्जेक्ट कॉन्टेक्स्ट का उपयोग करें ताकि उन्हें स्वचालित रूप से साझा और अपडेट किया जा सके। और बड़ी मात्रा में डेटा के लिए, एक नया अलग ऑब्जेक्ट कॉन्टेक्स्ट का उपयोग करें। कोई बेहतर विचार?
क्या कोई तरीका है कि कैसे अपने डेटाकॉन्टेक्स्ट से इकाइयों को "रिलीज़" करें ताकि कचरा कलेक्टर अपना काम कर सके और स्मृति जारी कर सके?
इस एप्लिकेशन के साथ, हम सिल्वरलाइट के बारे में बात कर रहे हैं। प्रिज्म/कैलिबर्न का उपयोग करके, मेरा मानना है कि एक ऑब्जेक्ट कॉन्टेक्स्ट प्रति दृश्य (मॉड्यूल?) रखने में कोई समस्या नहीं है। फिर, समस्या यह है कि अगर ग्राहक को बहुत सारे डेटा लोड किए जाएंगे? जहां तक मैं अब हूं, सबसे अच्छा समाधान उन सभी मूल संस्थाओं के लिए साझा ऑब्जेक्ट कॉन्टेक्स्ट बनाना होगा जो पूरे एप्लिकेशन के माध्यम से उपयोग किए जाते हैं ताकि ये स्वचालित रूप से सिंक्रनाइज़ हो जाएं, और ऑब्जेक्ट कॉन्टैक्स को डेटा के बड़े समूह को लोड करने के लिए अलग करें। कुछ ऐतिहासिक रिपोर्टें। – gius
मैं ग्राहक को डेटा के वास्तव में बड़े ब्लॉक भेजने की कोशिश नहीं करता। इसके बजाए, मैं सर्वर पर फ़िल्टर करता हूं और केवल उस परिणाम को वापस कर देता हूं जो ग्राहक उस पल में देखना चाहता है। मनुष्य 100,000 रिकॉर्ड नहीं पढ़ सकते हैं, इसलिए उन लोगों को मानव को न भेजें। इसके बजाए, समस्या को एक खोज/फ़िल्टर दें और केवल क्लाइंट को परिणाम भेजें। यदि आप रिपोर्ट बना रहे हैं, तो सर्वर पर कुल सारांश डेटा बनाएं। उदाहरण के लिए, सर्वर पर मासिक बिक्री वॉल्यूम की गणना करना बेहतर होगा और 5000 बिक्री रिकॉर्ड देखने के बजाय ग्राहक को एक ही नंबर भेजना बेहतर होगा। –
यह सच है, लेकिन यदि उपयोगकर्ता किसी भी समय एप्लिकेशन जीवन के दौरान देखता है तो मान लें कि पेज 1, 10, 20, वे डेटा अभी भी स्मृति में होंगे। दूसरी ओर, एक अलग ऑब्जेक्ट कॉन्टेक्स्ट और डेटा पेजिंग का उपयोग करके बड़े डेटा-रहने-इन-मेमोरी समस्या को हल कर सकते हैं। – gius