इकाई फ्रेमवर्क 4: क्या सभी संस्थाओं के लिए एक आरेख बनाने के लिए यह समझ में आता है?

Question

मैंने एंटिटी फ्रेमवर्क के बारे में कुछ मान्यताओं को लिखा, फिर कुछ प्रश्न (इसलिए कृपया सही करें कि मैं कहां गलत हूं)।

• केवल एक डेटा संदर्भ एक एफई आरेख के लिए मौजूद कर सकते हैं: मैं एफई के साथ Pocos उपयोग करने के लिए 4.

  मेरे मान्यताओं कोशिश कर रहा हूँ।

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

यह मानते हुए कि सही है, यहाँ मेरे सवालों हैं:

• आप एक ही एफई चित्र पर सभी संस्थाओं नहीं रखते हैं, तो कैसे आप डेटा अखंडता को बनाए रखने है, "आदेश" की तरह मौजूद नहीं कर सकते एक "ग्राहक" के बिना? क्या यह केवल अखंडता को सत्यापित करने के लिए डेटा लोड करने के लिए भंडार का एक कार्य है, या क्या हम डेटाबेस संदर्भित अखंडता त्रुटियों पर "कोशिश/पकड़" करते हैं?

• क्या आप प्रत्येक इकाई के लिए ईएफ आरेख नहीं बनाएंगे? उदाहरण के लिए, मैं किसी ग्राहक को परिवर्तन की अपेक्षा नहीं करता और उत्पाद को एक साथ लिखने के लिए बदलता हूं क्योंकि उनके पास एक दूसरे के साथ कुछ नहीं करना है (उन्हें उसी आरेख पर रखने से उन्हें एक साथ लिखा जाएगा)। या एक ईएफ आरेख का दायरा एक ही स्टोरेज माध्यम में संग्रहीत सभी समान इकाइयों को शामिल करने के लिए है?

क्या यह इस तरह की इकाइयों को विभाजित करने का मानक है, या सिर्फ सभी इकाइयों को रखने वाला एक आरेख है? मैं बाद वाले को सोचूंगा, लेकिन सोच मेरे लिए बेहतर हो रही है।

Answer 1

सभी संस्थाओं वाले एक बड़े ईडीएम को आम तौर पर एक अच्छा अभ्यास नहीं है और इसकी अनुशंसा नहीं की जाती है।
एक बड़े ईडीएम का उपयोग करते हुए इस तरह के रूप में कई समस्याओं का कारण बन जाएगा: मेटाडाटा लोड समय में

प्रदर्शन मुद्दा:
स्कीमा फ़ाइलें वृद्धि के आकार के रूप में, समय यह पार्स और एक में बनाने के लिए ले जाता है इस मेटाडाटा के लिए स्मृति मॉडल भी बढ़ेगा। देखें पीढ़ी में

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

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

Intellisense अनुभव महान नहीं है:
1000 तालिकाओं का कहना है कि जब आप किसी डेटाबेस से एक EDM मॉडल तैयार करते हैं तो 1000 विभिन्न इकाई सेट के साथ खत्म हो जाएगा। कल्पना करें कि जब आप वीएस कोड विंडो में "संदर्भ" टाइप करते हैं तो आपका इंटेलिजेंस अनुभव कैसा होगा।

बरबाद CLR नेमस्पेस:
के बाद से एक मॉडल स्कीमा एक भी ईडीएम नाम स्थान होगा, उत्पन्न कोड एक भी नाम स्थान में कक्षाएं स्थापित करेंगे।

एक अधिक विस्तृत चर्चा के लिए, Working With Large Models In Entity Framework – Part 1 पर एक नजर है

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

भले ही इस प्रकार का अलगाव 100% संभव न हो - जिसका अर्थ है कि डेटाबेस में अन्य तालिकाओं के लिए विदेशी कुंजी जाने वाले टेबल के सबसेट हैं - यह अभी भी आपको प्रोत्साहित करता है कि आप उन्हें अलग करें। जब आप ऐसा करते हैं, तो आपको विदेशी कुंजी को उचित रूप से स्थापित करने की ज़िम्मेदारी लेनी होगी। कोई नेविगेशन प्रॉपर्टी नहीं होगी जो आपको इस विदेशी कुंजी का प्रतिनिधित्व करने वाली संस्था प्राप्त करने की अनुमति देती है। बेशक यदि आप आवश्यक हो तो अन्य कंटेनर में इस इकाई के लिए मैन्युअल रूप से पूछ सकते हैं। Working With Large Models In Entity Framework – Part 2

अपने प्रश्न के बारे में:: आदेश और

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

Answer 2

मुझे एहसास हुआ कि यह प्रश्न लगभग ईएफ 4 था, लेकिन मुझे यकीन है कि बहुत से लोग जो अभी "स्विच कर रहे हैं" Google के माध्यम से यहां समाप्त हो जाएंगे और इसे पढ़ेंगे और अनुमोदित उत्तर और इसके आधार पर निर्णय लेंगे यहां तक ​​कि वे EF5 उपयोग कर रहे हैं (या EF4.4 अगर आप नेट 4.0 पर फंस रहे हैं)

EF5 हालांकि कई चित्र edmx प्रति अनुमति देता है। यह कम से कम मेरी टीम के लिए एक बड़ा सौदा है, क्योंकि यह हमें अलग-अलग edmx फ़ाइलों की आवश्यकता के बिना दृष्टि से अलग इकाइयों को देखने की अनुमति देता है। डॉ। ज़िम के अंक अभी भी स्पष्ट रूप से "अव्यवस्थित डिजाइनर सतह" को छोड़कर मान्य हैं।

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

"लेकिन सामान्यीकरण अच्छा बात है, है ना?" खैर, अगर आप एक रिलेशनल डेटाबेस हाँ का उपयोग कर रहे हैं। "लेकिन अगर मैं ईएफ का उपयोग कर रहा हूं तो यह क्यों मायने रखता है?" एक आम "सामान्यीकृत" तालिका पता है। संभावित परिदृश्य: कंपनी (व्यवसाय/कार्यालय का स्थान) और संपर्क ("रिमोट" कर्मचारी हो सकता है ताकि वे व्यावसायिक स्थान पर न हों) और दोनों के पास एक एफके है जो पता को इंगित करता है। कंपनी के लिए एक edmx फ़ाइल और संपर्क (यहां तक ​​कि विभिन्न नामस्थान के साथ) के लिए एक है कि दोनों पता तालिका में शामिल हैं का उपयोग करना, कोड संकलन होगा, लेकिन रन टाइम पर आप इस सुंदरता मिल जाएगा:

Multiple types with the name 'Address' exist in the EdmItemCollection 
in different namespaces. Convention based mapping requires unique names 
without regard to namespace in the EdmItemCollection 

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

आप पता तालिका के लिए क्रमशः "संपर्क एड्रेस" और "कंपनी एड्रेस" के लिए मॉडल नाम का नाम बदल सकते हैं, लेकिन यह भ्रम देता है कि वे वास्तव में अलग-अलग प्रकार के होते हैं। ठीक है, इसलिए वे ईएफ में विभिन्न प्रकार हैं लेकिन डेटाबेस में नहीं हैं, और जैसा कि मैंने कहा है, हम में से अधिकांश मौजूदा डेटा स्टोर के साथ मौजूदा सिस्टम में ईएफ पर काम करने की दुनिया में "लाइव" हैं जो एक रिलेशनल डेटाबेस है।

यह पहले से ही एक लंबा हवादार "उत्तर" है इसलिए मैं यहां रुक जाऊंगा। मैं बस यह सुनिश्चित करना चाहता था कि जो लोग यहां उतरे क्योंकि उन्होंने "एकाधिक एडीएमएक्स" की खोज की और उन्हें एहसास नहीं हुआ कि ईएफ 4 और ईएफ 5 के बीच महत्वपूर्ण अंतर जागरूक थे और उन्हें एहसास हुआ कि उन्हें कुछ और जांच करने की आवश्यकता हो सकती है।