🧒🏻 ⚒️ 👎🏼 संस्थाओं, डीटीओ, ओआरएम, और आलसी लोड के बारे में 👴🏿 ➡️ 🍥

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

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

सब कुछ डाउनलोड करें और मेमोरी / टाइमआउट से बाहर आएं
स्पष्ट रूप से इंगित करें कि हम किन निर्भरताओं को डाउनलोड करना चाहते हैं और कौन से नहीं, और सिद्धांत का उल्लंघन न करें का उल्लंघन करें
लोड निर्भरता स्पष्ट रूप से आलसी लोड का उपयोग करने की मांग पर है और कहीं न कहीं कोड में प्रदर्शन की समस्याएं प्राप्त करती हैं

आपको किस तरह का पैर काटना चाहिए: बाएं या दाएं?

TLDR आलसी लोड इतना बुरा नहीं है यदि केवल लिखने के लिए उपयोग किया जाता है और पढ़ने के दौरान उपयोग नहीं किया जाता है। लेकिन सब कुछ इतना सरल नहीं है और बहुत सारी बारीकियां हैं।

समय के साथ, मैं इस नतीजे पर पहुंचा कि आलसी लोड और / या ओआरएम के कार्यान्वयन पर संस्थाओं की निर्भरता कुछ शर्तों के तहत कम बुराई है।

रीड सबसिस्टम में, हमेशा केवल डीटीओ पढ़ें

90% मामलों में, पढ़ने के दौरान आलसी लोड के साथ समस्याएं ठीक होती हैं। हम संस्थाओं की सूची प्राप्त करते हैं, इसके माध्यम से जाते हैं और लूप करते हैं और सभी आवश्यक डेटा का चयन करना शुरू करते हैं। हम डेटाबेस के लिए प्रश्नों का एक शाफ्ट प्राप्त करते हैं। इस मामले में, सबसे अधिक बार केवल एक चीज की आवश्यकता होती है जो डेटा प्राप्त करने के लिए है, इसे क्रमबद्ध करें और इसे JSON के रूप में वापस भेजें। फिर, संस्थाओं पर भार क्यों? पूरे ट्रैक को "अतिरिक्त" फ़ील्ड के साथ पढ़ने के लिए, इस डेटा को परिवर्तन ट्रैकर UOW में जोड़ने की कोई आवश्यकता नहीं है। इसके बजाय, आप हमेशा या तो Select या ProjectTo लिख सकते हैं। आलसी लोड की आवश्यकता नहीं है क्योंकि Select से C # कोड को SQL में अनुवादित किया जाएगा और डेटाबेस साइड पर निष्पादित किया जाएगा।

यदि मेरा तर्क एसक्यूएल में अनुवाद नहीं करता है तो क्या होगा?

मैं क्लाइंट मूल्यांकन बंद रखने की सलाह देता हूं। सबसे पहले, आप "सहायता" कर सकते हैं और उप में सीधे आवश्यक कार्यों के लिए समर्थन जोड़ सकते हैं। साधारण कंप्यूटिंग की बात आती है तो कोई बुरा विकल्प नहीं है, न कि व्यावसायिक नियम। विकल्प संख्या दो: इकाई से इंटरफ़ेस निकालें और इसे इकाई और डीटीओ दोनों में लागू करें।

उदाहरण के लिए, डेटाबेस में दो क्षेत्र हैं: "बिना छूट के मूल्य" और "छूट के साथ मूल्य"। यदि फ़ील्ड "छूट मूल्य" भरा है, तो इसका उपयोग करें, यदि नहीं, तो सामान्य मूल्य के साथ फ़ील्ड का उपयोग करें। एक और नियम जोड़ें। 3 उत्पादों को खरीदते समय, आप केवल 2 सबसे महंगे लोगों के लिए भुगतान करते हैं, जबकि नियमित छूट को भी ध्यान में रखा जाता है।

कार्यान्वयन इस प्रकार हो सकता है:

 public interface IHasProductPrice { decimal BasePrice { get; } decimal? SalePrice { get; } } public class Product: IHasProductPrice { // ... a lot of code public decimal BasePrice { get; protected set;} public decimal? SalePrice { get; protected set;} } public class ProductDto: IHasProductPrice { public decimal BasePrice { get; set;} public decimal? SalePrice { get; set;} } public static class ProductCalculator { public static void decimal Calculate(IEnumerable<IHasProductPrice> prices) }

सबसिस्टम में, आलसी लोड इतना डरावना नहीं है

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

समुच्चय में संबद्ध संग्रह

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

क्या होगा अगर एग्रीगेट में अभी भी हजारों रिकॉर्ड हैं?

DbContext को DbContext पास करें और इससे केवल ऑपरेशन के संदर्भ में आवश्यक डेटा पढ़ें। हां, डीआईपी का उल्लंघन करें। या तो वह, या इस मामले में इकाई का उपयोग न करें।

बड़े पैमाने पर संचालन

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

जीवन हैक

यदि आपको एक बड़े पैमाने पर ऑपरेशन और पारंपरिक दोनों को लागू करने की आवश्यकता है, तो आपको बड़े पैमाने पर शुरुआत करने की आवश्यकता है। एक सामान्य ऑपरेशन केवल एक तत्व के साथ अनुक्रम में बड़े पैमाने पर कोड का एक विशेष मामला है।

संस्थाओं, डीटीओ, ओआरएम, और आलसी लोड के बारे में