MongoDB और C #। नई सुविधाएँ और स्पष्ट चुनौतियाँ

परिचय

जुलाई की शुरुआत में, C # के लिए आधिकारिक MongoDB ड्राइवर का अगला संस्करण (1.5) जारी किया गया था। नवाचारों के बीच, यह टाइप किए गए प्रश्नों के लिए ध्यान देने योग्य है। अब आप अभिव्यक्ति के साथ संयोजन में लैम्ब्डा कार्यों का उपयोग कर सकते हैं।
इस लेख में मैं एक नए वाक्यविन्यास के उदाहरण दिखाऊंगा जो मुझे वास्तव में पसंद है (और मुझे वास्तव में C # में अभिव्यक्ति पसंद है), और उन प्रश्नों के उदाहरण भी प्रदर्शित करते हैं जहां, अफसोस, अभिव्यक्ति हमारी मदद नहीं करेगी और सामान्य रेखाओं पर लौटना होगा। मैं यह भी चर्चा करता हूं कि ऐसा क्यों है और क्या किसी दिन MongoDB के साथ काम करते समय C # में सब कुछ ठीक होगा।

ओह अच्छा

हाँ, अब इसके बजाय:

ObjectId articleId = new ObjectId("dgdfg343ddfg"); IMongoQuery query = Query.EQ("_id", articleId); 

आप इस तरह लिख सकते हैं:

 ObjectId articleId = new ObjectId("dgdfg343ddfg"); IMongoQuery query = Query<Article>.EQ(item => item.Id, articleId); 

कक्षा अनुच्छेद की उपस्थिति में, निश्चित रूप से, जो दस्तावेज़ की रूपरेखा का प्रतिनिधित्व करता है। यह ध्यान देने योग्य है कि QueryBuilder <T> चयन से संबंधित सभी विधियां पूरी तरह से QueryBuilder के समान हैं। सच है, प्रश्नों को संयोजित करने के लिए, आपको अभी भी Query.And या Query.Or का उपयोग करना होगा। ठीक है, यह समझ में आता है, क्योंकि सभी तरीके एक ही QueryBuilder को वापस करते हैं। वास्तव में, उन्हें आपकी इच्छानुसार जोड़ा जा सकता है।
UpdateBuilder ने उपयुक्त विधियों के साथ UpdateBuilder <T> भी पेश किया।
जैसा कि पहले था:

 Article article = new Article(); IMongoUpdate update = Update.PushWrapped("Articles", article); 

अब मैं कैसे कर सकता हूं:

 Article article = new Article(); IMongoUpdate update = Update<Article>.Push(item => item.Articles, article); 

मेरी राय में, बहुत बेहतर (यदि हम सुंदरता और नियंत्रण के बारे में बात करते हैं)। सामान्य तौर पर, अभिव्यक्ति पेड़ एक बहुत शक्तिशाली और सुंदर चीज है। यहाँ, केवल हिमशैल के बहुत टिप, लेकिन मैंने उन्हें बहुत उपयोग किया है जहां। कई मायनों में, यह एक मानवीय चेहरे के साथ प्रतिबिंब है।
ओह ठीक है। यहां सब कुछ सरल लगता है। चलिए कम खूबसूरत चीजों की ओर बढ़ते हैं।

ओह दुखद

मूल्य द्वारा खोज जैसे सरल प्रश्न एक धमाके के साथ बंद हो जाते हैं। थोड़ा और अधिक जटिल, वैसे भी। उदाहरण के लिए, सरणी में एक तत्व की खोज:

 IMongoQuery query = Query<Article>.ElemMatch<Comment>(item => item.Comments, builder => builder.EQ(item => item.Id, comment.Id)); 

लेकिन तनाव पहले से ही महसूस किया जा रहा है।
अब कोयले को पलटते हैं। इस सामग्री का एक दस्तावेज है:

 _id : "s3d4f5d6sf", array1 : [{ _id : "cv434lfgd45", array2 : [{ _id : "df4gd45g43f4", name : "Logic" }, { ... }] }, { ... }] 

और अब हमारे पास array2 array में एक और तत्व जोड़ने का काम है। कार्यक्रम में:

1) मुख्य दस्तावेज़ डॉक्टर मॉडल वर्ग द्वारा वर्णित किया जाएगा
2) array1 को List <Item1> में बदल दें, जहां Item1 array1 के प्रत्येक तत्व के लिए मॉडल वर्ग है
3) हम array2 को List <Item2> में बदल देते हैं, जहां Item2 array2 के प्रत्येक तत्व के लिए मॉडल क्लास है

(मैंने जानबूझकर दस्तावेज़ को अज्ञात किया ताकि डेटा संरचना के बारे में कोई शिकायत न हो)

समस्याओं को खोजने में कोई समस्या नहीं है:

 IMongoQuery query = Query.And( Query<Doc>.EQ(item => item.Id, new ObjectId("s3d4f5d6sf")), Query<Doc>.ElemMatch<Item1>(item => item.Array2, builder => builder.EQ(item => item.Id, new ObjectId("df4gd45g43f4"))); 

लेकिन कठिनाइयों को अद्यतन करने के अनुरोध के साथ (मैं जानबूझकर किसी दस्तावेज़ का चयन करने, उसके साथ डेटा जोड़ने और फिर डेटाबेस में लिखने के विकल्प पर विचार नहीं करता हूं। क्योंकि विकल्प बहुत अधिक उप-प्रकार है। इसके अलावा, मैं नमूनों के कैस्केड के बजाय एक परमाणु संचालन में डेटा को अपडेट करना चाहूंगा / करूंगी। रिकॉर्ड)। आपको नेस्टेड array2 array पर जाना होगा। यदि आप MongoDB के मानक टूल का उपयोग करते हैं, तो आप यह कर सकते हैं:

 IMongoUpdate update = Update.PushWrapped<Item2>("array1.$.array2", new Item2()); 

मैं यह नहीं जान सका कि मैजिक लाइनों के आसपास कैसे पहुंचा जा सकता है, और जितनी देर मैंने अभिव्यक्ति "array1। $। Array2" पर देखा, मेरे पास और अधिक संदिग्ध विचार थे।

ऊँ ऊँ

चलो शुरू से।

"स्थिर" भाषाएं हैं। उदाहरण के लिए, सी #। उनमें, संकलन (सबसे अधिक बार) से पहले तत्वों की संरचना ज्ञात है। और यह इन संरचनाओं के साथ है जो हम संचालित करते हैं। विशेष रूप से, हम कक्षाओं, ऐसी योजनाओं के साथ काम करते हैं। ठीक है, डेटा पक्ष पर, हमारे पास ऑब्जेक्ट हैं - कक्षाओं के उदाहरण।

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

डेटा के संगठन में, आप एक निश्चित सादृश्य भी आकर्षित कर सकते हैं।
रिलेशनल डेटाबेस में हार्ड डेटा स्कीमा और उनके बीच निर्भरताएं होती हैं।
दस्तावेज़-उन्मुख में केवल दस्तावेज़, घोंसले के शिकार और सूचियाँ हैं।

और अब मैं कल्पना करूंगा और अधिक क्रूड एनालॉग दूंगा।
"Array1। $। Array2" के मामले में अभिव्यक्ति के साथ क्वेरी करने में समस्या यह है कि C # में हम दस्तावेज़ों (ऑब्जेक्ट्स) के साथ काम करने के लिए संरचनाओं (कक्षाओं) के साथ काम करते हैं। अनुरोध की "शक्ति" आग में ईंधन जोड़ती है। यदि हम चयन अनुरोध में केवल पहली शर्त छोड़ते हैं, तो अगर हम चाहें (ध्वज को मल्टीपडेट में स्थापित करें), तो हम array2 सरणियों में से प्रत्येक में एक तत्व जोड़ सकते हैं। वास्तव में, वास्तव में, हमारी सुंदर क्वेरी (भले ही हम इसे लिख सकते हैं) अभी भी "array1। $। Array2" में परिवर्तित हो जाएगी। घोंसले के गहरे स्तर के साथ अधिक व्यापक दस्तावेज के लिए, स्थिति केवल खराब हो जाएगी।

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

निष्कर्ष

मुझे MongoDB के साथ काम करने का अधिक अनुभव नहीं है, और मैं लेख में वर्णित क्वेरी समस्या के समाधान के साथ-साथ MongoDB के लिए C # में आर्किटेक्चर और कोड बनाने के विषय पर तर्क / बहस का तर्क शामिल करूंगा।