बड़े सिस्टम के साथ एंटिटी फ्रेमवर्क - मॉडल कैसे विभाजित करें?


50

मैं 1000+ तालिकाओं के साथ SQL सर्वर डेटाबेस के साथ काम कर रहा हूँ, कुछ सौ विचार, और कई हजार संग्रहीत कार्यविधियाँ। हम अपनी नई परियोजनाओं के लिए एंटिटी फ्रेमवर्क का उपयोग शुरू करना चाहते हैं, और हम ऐसा करने के लिए अपनी रणनीति पर काम कर रहे हैं। मैं जिस चीज पर लटका हुआ हूं वह यह है कि तालिकाओं को अलग-अलग मॉडल (EDMX या DbContext में विभाजित किया जाए तो सबसे अच्छा है कि हम कोड कहां जाएं)। मैं बल्ले से कुछ रणनीतियों के बारे में सोच सकता हूं:

  • स्कीमा द्वारा
    विभाजित हमारे पास हमारे टेबल शायद एक दर्जन स्कीमाओं में विभाजित हैं। हम स्कीमा प्रति एक मॉडल कर सकते हैं। यह सही नहीं है, हालांकि, क्योंकि अभी भी dbo 500+ तालिकाओं / विचारों के साथ बहुत बड़ा है। एक अन्य समस्या यह है कि काम की कुछ इकाइयाँ कई मॉडल का लेनदेन करने वाले लेनदेन को समाप्त कर देंगी, जो जटिलता में जोड़ता है, हालांकि मुझे लगता है कि ईएफ इसे काफी सरल बनाता है।
  • इरादे से
    विभाजित करें स्कीमा के बारे में चिंता करने के बजाय, इरादे से मॉडल को विभाजित करें। इसलिए हमारे पास प्रत्येक एप्लिकेशन, या प्रोजेक्ट, या मॉड्यूल या स्क्रीन के लिए अलग-अलग मॉडल होंगे, यह इस बात पर निर्भर करता है कि हम किस प्रकार का दाना प्राप्त करना चाहते हैं। मैं इसके साथ जो समस्या देख रहा हूं, वह यह है कि कुछ निश्चित तालिकाएँ हैं, जिन्हें अनिवार्य रूप से हर मामले में उपयोग किया जाना है, जैसे कि उपयोगकर्ता या ऑडिटहिस्टोर। क्या हम उन्हें हर मॉडल में जोड़ते हैं (DRY I think का उल्लंघन करता है), या वे एक अलग मॉडल में हैं जो हर प्रोजेक्ट के द्वारा उपयोग किया जाता है?
  • बिल्कुल भी विभाजित न करें - एक विशाल मॉडल
    यह स्पष्ट रूप से एक विकास के दृष्टिकोण से सरल है, लेकिन मेरे शोध और मेरे अंतर्ज्ञान से ऐसा लगता है कि यह बहुत अच्छा प्रदर्शन कर सकता है, दोनों डिजाइन समय पर, संकलन समय, और संभवतः समय चला सकते हैं।

इतने बड़े डेटाबेस के खिलाफ ईएफ का उपयोग करने के लिए सबसे अच्छा अभ्यास क्या है? विशेष रूप से डीबी ऑब्जेक्ट्स के इस वॉल्यूम के खिलाफ मॉडल डिजाइन करने में लोग किन रणनीतियों का उपयोग करते हैं? क्या ऐसे विकल्प हैं जो मैं उस काम के बारे में नहीं सोच रहा हूं जो मैंने ऊपर दिया है?

इसके अलावा, क्या एनएचबीर्नेट जैसे अन्य ओआरएम में यह समस्या है? यदि ऐसा है तो वे ईएफ की तुलना में किसी भी बेहतर समाधान के साथ आए हैं?


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

@ टार्टार्ट धन्यवाद मैंने MS DTC का उपयोग पहले और बाद में किया है, जबकि यह बहुत सरल है, यह एक साधारण DB txn से परे जटिलता को जोड़ता है इसलिए मैं जब भी संभव हो, इससे बचना चाहता हूं।
रेशनलगीक

2
4 साल बाद, आपने क्या फैसला किया और अब आप क्या सलाह देंगे?
रोरी

जवाबों:


31

व्यक्तिगत रूप से, मैंने अपने सभी संस्थानों के लिए एक बहुत ही जटिल लेकिन छोटी परियोजना (~ 300 टेबल) पर एक विशाल स्कीमा बनाने की कोशिश की है। हमारे पास एक अत्यंत सामान्यीकृत डेटाबेस (5 वां रूप सामान्यीकरण (मैं कहता हूं कि शिथिल)) कई "कई से कई" रिश्तों और अत्यधिक संदर्भात्मक अखंडता प्रवर्तन के साथ है।

हमने "अनुरोध के अनुसार एकल उदाहरण" रणनीति का भी उपयोग किया, जो मुझे विश्वास नहीं है कि या तो मदद नहीं की गई है।

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

इसलिए मेरे अनुभव के आधार पर, मैं प्रति इरादा एक अलग .edmx बनाने की सलाह दूंगा। केवल वही उत्पन्न करें जो आप उस आवश्यकता के दायरे के आधार पर उपयोग करेंगे। आपके पास purposed कार्यों के लिए कुछ छोटी scoped .edmx फाइलें हो सकती हैं, और फिर कुछ बड़े लोग जहां आपको ऑब्जेक्ट बनाने के लिए जटिल रिश्तों की आवश्यकता होती है। मुझे यकीन नहीं है कि वह जादू कहाँ है, लेकिन मुझे यकीन है कि वहाँ एक है ... योग्य ...

ईमानदारी से, हालांकि, कुछ नुकसानों से अलग, जिन्हें हमने देखा है (जटिल ट्रैवर्सिंग), विशाल .edmx ने "काम" के दृष्टिकोण से ठीक काम किया। लेकिन आपको "फ़िक्सअप" जादू के लिए बाहर देखना होगा जो संदर्भ दृश्य के पीछे करता है यदि आप इसे स्पष्ट रूप से अक्षम नहीं करते हैं। डेटाबेस में परिवर्तन किए जाने पर .edmx को सिंक में रखने के साथ-साथ .. पूरी सतह को पोंछना और संस्थाओं को फिर से बनाना आसान था, जिसमें 3 मिनट लगते थे इसलिए यह कोई बड़ी बात नहीं थी।

यह सब EntityFramework 4.1 के साथ था। मैं वास्तव में आपकी अंतिम पसंद और अनुभव के बारे में सुनना चाहूंगा।

और के बारे में आप nHibernate पर सवाल कर रहे हैं, कि मेरी राय में कीड़े का एक सवाल है, तो आप बाड़ के दोनों किनारों पर भौंकने मिल जाएगा ... मैं बहुत से लोगों को ईएफ को कोसने के लिए कोसने के लिए बिना काम किए सुना है चुनौतियां और स्वयं ईएफ के लिए विशिष्ट बारीकियों को समझना .. और हालांकि मैंने कभी भी उत्पादन में एनहाइबनेट का उपयोग नहीं किया है, आम तौर पर, यदि आपको मैन्युअल रूप से और स्पष्ट रूप से मैपिंग जैसी चीजों का निर्माण करना है, तो आप अधिक परिमित नियंत्रण प्राप्त करने जा रहे हैं, हालांकि, यदि आप n 'ड्रॉप, जेनरेट कर सकते हैं, और LINQ का उपयोग करके CRUD'ing और क्वेरी करना शुरू कर सकते हैं, मैं ग्रैन्युलैरिटी के बारे में एक बकवास दे सकता हूं।

आशा है कि ये आपकी मदद करेगा।


1
FYI करें - एक NHibernate मैपिंग उपयोगिता है जो इन मैपिंग को बहुत आसान और स्वचालित बनाती है।
गैंडर्स

@ganders - क्या इसमें UI है और यह IDE एकीकरण कैसे है? मैं मान रहा हूं कि आप इसे डेटा स्रोत की ओर इंगित करते हैं और यह संदर्भात्मक अखंडता और ऑब्जेक्ट ट्रैवर्सल का सम्मान करता है और मैपिंग ऑब्जेक्ट बनाता है?
हेंज़ोलो

1
हाँ यह (GUI) करता है। मेरे पास इसके साथ अब तक शून्य मुद्दे हैं। 4 या 5 विभिन्न परियोजनाओं / वेबसाइटों पर इसका इस्तेमाल किया। नोट: मैं इसे धाराप्रवाह NHibernate के साथ उपयोग करता हूं, जो कि सी # कोड में मैपिंग करता है, कॉन्फ़िगरेशन / xml फ़ाइलों में नहीं। : यहाँ एक लिंक भी है nmg.codeplex.com
Ganders

13

मुझे सरल स्पष्टीकरण से शुरू करना चाहिए: मेरे पास ऐसे बड़े डेटाबेस के साथ अनुभव नहीं है, इसलिए मेरा बाकी का जवाब वास्तविक दुनिया के उदाहरण पर आधारित नहीं है।

तो आपके पास एक BIG डेटाबेस है और आप इसका उपयोग ORM / EF के साथ करना चाहते हैं। मैं दूसरी पसंद के साथ जाऊंगा। यहाँ मेरी सरल व्याख्या क्यों है:

  • मानचित्रण जटिलता जोड़ता है। आपके वर्तमान एप्लिकेशन / प्रोजेक्ट / मॉड्यूल को उन संस्थाओं के साथ जटिलता जोड़ने की कोई आवश्यकता नहीं है जिनकी कभी भी आवश्यकता नहीं होती है, लेकिन यह बहुत कम स्तर नहीं बनाता है। प्रति स्क्रीन पर अलग मैपिंग सेट होने से आपकी मदद नहीं होगी।
  • आप काम की इकाई को प्राप्त करना चाहते हैं। आपको यह निर्दिष्ट करने में सक्षम होना चाहिए कि अधिकांश मामलों में टेबल मॉड्यूल की क्या आवश्यकता है (सभी मामलों में आवश्यक नहीं)। यदि आप इन तालिकाओं को एकल मैपिंग सेट में रखते हैं, तो आप एकल संदर्भ उदाहरण द्वारा रीडिंग और डेटा संशोधन को संभालने में सक्षम होंगे - यही आपका अंतिम लक्ष्य होना चाहिए।
  • मुझे यकीन नहीं है कि आप वास्तव में मॉडल से क्या मतलब है, लेकिन यहां तक ​​कि विभिन्न मानचित्रण सेटों के साथ आप समान इकाई प्रकारों का उपयोग करके मैपिंग सेटों के बीच कक्षाएं साझा कर सकते हैं। इसलिए यदि आप दो मॉड्यूल में उपयोगकर्ता तालिका का उपयोग करते हैं तो आपको उसी का प्रतिनिधित्व करने के लिए दो उपयोगकर्ता वर्गों की आवश्यकता नहीं है। आप अभी भी सिंगल टेबल का उपयोग कर सकते हैं और कोड मैपिंग (उर्फ कोड-प्रथम) के मामले में भी आप एक बार मैपिंग को परिभाषित कर सकते हैं और इसे कई मैपिंग सेट पर लोड कर सकते हैं ताकि DRY सिद्धांत का उल्लंघन न हो लेकिन जब यह आता है तो कोड-प्रथम दृष्टिकोण की अधिक सीमाएं होती हैं। विचारों और संग्रहीत प्रक्रियाओं के लिए। EDMX इसे कठिन बनाता है। आप अभी भी कक्षाओं का पुन: उपयोग कर सकते हैं लेकिन मैपिंग को असंभव बना सकते हैं।
  • क्रॉस मॉड्यूल प्रश्नों के बारे में क्या? ये प्रश्न हो सकते हैं लेकिन ईमानदार होने के लिए सब कुछ ईएफ द्वारा नियंत्रित किया जाना चाहिए। आप नियमित डेटा एक्सेस को आसान बनाने के लिए सामान्य मामलों के लिए ईएफ का लाभ उठा सकते हैं लेकिन अगर आपको कहीं विशेष क्वेरी की आवश्यकता है जो 5 अलग-अलग मॉड्यूल से संबंधित तालिकाओं में मिलती है तो आप इसे सीधे निष्पादित कर सकते हैं या इसे संग्रहीत कार्यविधि में लपेट सकते हैं। मूल डेटा पहुंच का 100% प्रतिस्थापन कठिन, जटिल और गर्भ-उत्पादक हो सकता है।
  • अंतिम बिंदु केवल व्यावहारिक है: मुझे विश्वास नहीं है कि वी.एस. टूलींग वस्तुओं के इतने बड़े सेट के साथ काम करने के लिए तैयार है - डिजाइनर में नहीं, आयात करने वाले टूल के साथ भी नहीं। मैं VS2008 में पारंपरिक डेटा एक्सेस और SQL डेटाबेस प्रोजेक्ट के साथ बहुत बड़े डेटाबेस पर काम करता था - एक जटिल प्रोजेक्ट के साथ उपयोगकर्ता का अनुभव बहुत खराब था। आपको उपयोग की गई तालिकाओं की संख्या कम रखनी चाहिए - डिजाइनर के लिए टोपी 100-200 के बीच होनी चाहिए, लेकिन एकल संदर्भ (मैपिंग सेट) द्वारा संभाले गए 100 टेबल भी एक वर्ग के लिए बहुत अधिक जिम्मेदारी की तरह लगते हैं (मान लीजिए कि आपके पास 100 सेट गुण होंगे प्रसंग पर अवगत कराया - यह एक अच्छे डिजाइन की तरह नहीं दिखता है)।

4

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

"एक अच्छा वास्तुकार निर्णय नहीं किए गए निर्णय की संख्या को अधिकतम करता है।" रॉबर्ट सी। मार्टिन

http://cleancoder.posterous.com/architecture-deference


3

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


यह एक अच्छी रणनीति की तरह लगता है, लेकिन वास्तव में इस सवाल को संबोधित नहीं करता है कि विभिन्न ईएफ मॉडल में संस्थाओं को कैसे विभाजित किया जाए। क्या आपके पास एक मॉडल में सभी संस्थाएं हैं या आप किसी तरह से विभाजित और जीतते हैं?
RationalGeek

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

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

मैं कहता हूँ कि बड़े पैमाने पर ऑब्जेक्ट ट्री और एक सामान्यीकृत डेटा संरचना हाथ से जाने पर बड़े स्कीमा के साथ काम करते हुए
हेंज़ोलो

आप नियंत्रित करते हैं कि आप वस्तु के ग्राफ को कितना संतृप्त करना चाहते हैं।
निक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.