एंटिटी फ्रेमवर्क के साथ कोड पहले डिज़ाइन का उपयोग करने के 3 कारण
1) कम cruft, कम ब्लोट
एक .edmx मॉडल फ़ाइल और संबंधित कोड मॉडल उत्पन्न करने के लिए एक मौजूदा डेटाबेस का उपयोग करने से ऑटो उत्पन्न कोड के एक विशाल ढेर में परिणाम होता है। आपको लगता है कि इन उत्पन्न फ़ाइलों को छूने के लिए कभी भी ऐसा न करें कि आप कुछ तोड़ते हैं, या अगली पीढ़ी पर आपके परिवर्तन ओवरराइट हो जाते हैं। संदर्भ और इनिशलाइज़र को इस गंदगी में भी एक साथ जाम किया जाता है। जब आपको अपने उत्पन्न मॉडल में कार्यक्षमता जोड़ने की आवश्यकता होती है, जैसे कि गणना की गई केवल संपत्ति पढ़ी जाती है, तो आपको मॉडल वर्ग का विस्तार करने की आवश्यकता होती है। यह लगभग हर मॉडल के लिए एक आवश्यकता है और आप सब कुछ के लिए एक विस्तार के साथ समाप्त होता है।
कोड के साथ पहले आपके हाथ से कोड किए गए मॉडल आपके डेटाबेस बन जाते हैं। आपके द्वारा बनाई जा रही सटीक फ़ाइलें डेटाबेस डिज़ाइन को उत्पन्न करती हैं। कोई अतिरिक्त फ़ाइलें नहीं हैं और जब आप संपत्तियों को जोड़ना चाहते हैं या जो कुछ भी डेटाबेस के बारे में जानने की आवश्यकता नहीं है, तो एक क्लास एक्सटेंशन बनाने की आवश्यकता नहीं है। जब तक आप उचित वाक्यविन्यास का पालन करते हैं, तब तक आप उन्हें उसी कक्षा में जोड़ सकते हैं। बिल्ली, यदि आप चाहते हैं तो अपने कोड की कल्पना करने के लिए आप एक Model.edmx फ़ाइल भी बना सकते हैं।
2) ग्रेटर कंट्रोल
जब आप पहले DB जाते हैं, तो आप अपने आवेदन में उपयोग के लिए अपने मॉडल के लिए जो कुछ भी उत्पन्न करते हैं उसकी दया पर होते हैं। कभी-कभी नामकरण सम्मेलन अवांछनीय होता है। कभी-कभी रिश्ते और संगठन आप जो चाहते हैं वह काफी नहीं होते हैं। अन्य समय में आपके एपीआई प्रतिक्रियाओं पर आलसी लोडिंग व्रक के साथ गैर क्षणिक संबंध।
जबकि मॉडल पीढ़ी की समस्याओं के लिए लगभग हमेशा एक समाधान होता है जिसे आप चला सकते हैं, पहले कोड जाना आपको पूर्ण और ठीक दानेदार नियंत्रण देता है। आप अपने व्यापारिक मॉडल के आराम से अपने कोड मॉडल और डेटाबेस डिजाइन दोनों के हर पहलू को नियंत्रित कर सकते हैं। आप रिश्तों, बाधाओं और संघों को सटीक रूप से निर्दिष्ट कर सकते हैं। आप एक साथ प्रॉपर्टी कैरेक्टर लिमिट और डेटाबेस कॉलम साइज सेट कर सकते हैं। आप यह निर्दिष्ट कर सकते हैं कि कौन से संबंधित संग्रह उत्सुकता से भरे हुए हैं, या उन्हें क्रमबद्ध नहीं किया जाना चाहिए। संक्षेप में, आप अधिक सामान के लिए जिम्मेदार हैं लेकिन आप अपने ऐप डिज़ाइन के पूर्ण नियंत्रण में हैं।
3) डेटाबेस संस्करण नियंत्रण
यह बड़ा वाला है। वर्जनिंग डेटाबेस कठिन है, लेकिन कोड फर्स्ट और कोड फर्स्ट माइग्रेशन के साथ, यह बहुत अधिक प्रभावी है। क्योंकि आपका डेटाबेस स्कीमा पूरी तरह से आपके कोड मॉडल पर आधारित होता है, संस्करण द्वारा आपके स्रोत कोड को नियंत्रित करके आप अपने डेटाबेस को संस्करण में लाने में मदद कर रहे हैं। आप अपने संदर्भ आरंभीकरण को नियंत्रित करने के लिए ज़िम्मेदार हैं जो आपको बीज निश्चित व्यावसायिक डेटा जैसी चीजें करने में मदद कर सकता है। आप कोड प्रथम माइग्रेशन बनाने के लिए भी ज़िम्मेदार हैं।
जब आप पहली बार माइग्रेशन सक्षम करते हैं, तो एक कॉन्फ़िगरेशन क्लास और एक प्रारंभिक माइग्रेशन उत्पन्न होता है। प्रारंभिक माइग्रेशन आपका वर्तमान स्कीमा या आपकी आधार रेखा v1.0 है। उस बिंदु से आप उन माइग्रेशन को जोड़ देंगे जो संस्करणों के क्रम के साथ मदद करने के लिए एक विवरणक के साथ टाइमस्टैम्प और लेबल किए जाते हैं। जब आप पैकेज मैनेजर से ऐड-माइग्रेशन कहते हैं, तो एक नई माइग्रेशन फ़ाइल एक सब कुछ उत्पन्न करेगी जो आपके कोड मॉडल में एक यूपी () और DOWN () फ़ंक्शन दोनों में स्वचालित रूप से बदल गई है। UP फ़ंक्शन डेटाबेस में परिवर्तन लागू करता है, DOWN फ़ंक्शन उन घटनाओं में वही परिवर्तन हटा देता है जिन्हें आप रोलबैक करना चाहते हैं। क्या अधिक है, आप इन बदलाव फ़ाइलों को संपादित कर सकते हैं अतिरिक्त परिवर्तन जैसे कि नए विचार, अनुक्रमणिका, संग्रहीत कार्यविधियाँ, और जो भी हो। वे आपके डेटाबेस स्कीमा के लिए एक सच्चे संस्करण प्रणाली बन जाएंगे।
