क्या CodeFirst बड़े पैमाने पर अनुप्रयोगों के लिए अभिप्रेत है?

Question

मैं एंटिटी फ्रेमवर्क पर पढ़ रहा हूं, विशेष रूप से, EF 4.1 और इस लिंक का अनुसरण कर रहा हूं ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- फ्रेमवर्क-4.aspx ) और यह कोड फर्स्ट पर गाइड है।

मुझे यह साफ लगता है, लेकिन मैं सोच रहा था, क्या कोड फर्स्ट सिर्फ तेजी से विकास के लिए एक समाधान माना जाता है, जहां आप बिना किसी योजना के सिर्फ सही तरीके से कूद सकते हैं या यह वास्तव में बड़े पैमाने पर अनुप्रयोगों के लिए उपयोग करने का इरादा है?

Comments

मुझे लगता है कि मॉकिंग के लिए कोड-प्रथम दृष्टिकोण अधिक उपयुक्त है। तो, यह अधिक परीक्षण के अनुकूल है।

— गुलशन

कोड-प्रथम, बहुत कम से कम, आपके डीबीए को एक बेकाबू पट्टे पर काम करने के लिए एक उत्कृष्ट तकनीक है। इस प्रकार, यह सब बुरा नहीं हो सकता।

— 3Sphere

Answer 1

हो सकता है कि मेरे पास वहां कुछ डिटैक्टर हों, लेकिन जब मैंने हंसेलमैन और गुथेरी में से कुछ पोस्ट पढ़ीं, तो जूलिया लर्मन की किताब एंटिटी फ्रेमवर्क पर पढ़ी , मेरे पास कोड के साथ कठिन समय था। अनुप्रयोगों के निर्माण के अपने कई वर्षों में, मैंने कई रास्तों को छोड़ दिया है, दोनों को प्रक्रिया द्वारा, और पसंद से मजबूर किया गया है, और यह पाया है कि आवेदन बनाते समय डेटा-केंद्रित दृश्य लेते समय मुझे बहुत अधिक सफलता मिली है।

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

छोटे अनुप्रयोग एक अपवाद हो सकते हैं, लेकिन मैं अपने डेटा-केंद्रित दृष्टिकोण का उपयोग करना जारी रखूंगा।

Comments

यह हो सकता है क्योंकि दृष्टिकोण अभी भी मेरे लिए थोड़ा विदेशी है और मैं बाद में अपना मन बदल सकता हूं, लेकिन यहां तक ​​कि छोटे ऐप्स के लिए, मुझे लगता है कि मैं अभी भी पहले डेटाबेस से अधिक आरामदायक इमारत बनूंगा। यह अभी शुरू करने के लिए सबसे तार्किक बिंदु लगता है।

— रोबोशॉप

यहां तक ​​कि जब आप अपने डेटाबेस को CodeFirst पर आधार बनाते हैं, तब भी आप डेटा-केंद्रित दृष्टिकोण का उपयोग कर रहे हैं। आप केवल सख्त डेटाबेस के बजाय .Net कक्षाओं का उपयोग करके अपने डेटा को मॉडलिंग कर रहे हैं। यदि आप अपने डेटा को .net कक्षाओं में मॉडल कर सकते हैं, जो आपको डेटा का उपयोग करने के तरीके को जानने के लिए वैसे भी करना होगा, तो मैं यह नहीं देखता कि ईएफ़ को उस डेटा मॉडल का समर्थन करने के लिए स्कीमा बनाने के लिए कैसे एक बड़ी बाधा है।

— कलड्रेक्स

मैं यह भी जोड़ना चाहूंगा कि जब तक आप EF 5.0+ और .NET 4.5+ पर न हों, कोड पहले चुनना CompiledQuery ऑब्जेक्ट्स जेनरेट करने में सक्षम नहीं होने के कारण आपके एप्लिकेशन पर प्रदर्शन सीमाएं रखेगा। मैं वर्तमान में CodeFirst से डेटाबेस के लिए एक आवेदन को स्थानांतरित करने की प्रक्रिया में हूँ क्योंकि हम EF 4.3

— एस्टेबन ब्रेन

एक व्यावसायिक समस्या का तात्पर्य व्यावसायिक प्रक्रियाओं से है, जो व्यवहार का अर्थ है। डेटा आमतौर पर उस व्यवहार का एक साइड इफेक्ट होता है (जब तक कि आप साधारण CRUD ऐप्स के बारे में बात नहीं कर रहे हैं), इसलिए मेरे उत्पीड़न में पहले मॉडलिंग पर ध्यान केंद्रित करना बेहतर है, बजाय पहले एक DB मॉडलिंग पर।

— स्टीफन बिलिएट

Answer 2

मैं यह नहीं देखता कि बड़े उद्यम परियोजनाओं में CodeFirst का उपयोग क्यों नहीं किया जा सकता है। मैं कहूंगा कि मैं कई परियोजनाओं में EF CodeFirst का उपयोग करता हूं, एक जहां डेटाबेस मेरे EF CodeFirst मॉडल द्वारा उत्पन्न होता है और दूसरा जहां EF CodeFirst एक मौजूदा डेटाबेस में मैप किया जाता है।

मेरे अनुभव से, सीएफ एक बड़ी परियोजना में कितना प्रभावी है, यह इस बात पर निर्भर करता है कि आपकी डेटा परत आपके व्यवसाय की परत से कितनी अलग है।

उदाहरण के लिए, मेरी एक परियोजना में व्यापार परत सीधे डेटाबेस को लाइनक के माध्यम से बुलाती है। मैं अपने डेटाबेस लेयर को अलग करने के लिए Linq का उपयोग करता हूं और डेटाबेस स्कीमा में अपने POCOs को मैप करने के लिए CodeFirst का उपयोग करता हूं। इस स्थिति में कोडफ़र्स्ट डीबी कन्वेंशन (रिलेशनशिप और टेबल नेम) और मेरे सी # क्लास के नामों के बीच के अंतर को बनाए रखने की क्रिया को बहुत सरल बना देता है, और मैं डेटाबेस में बदलाव कर सकता हूं बिना इस बात को प्रभावित किए कि मेरा बिजनेस लेयर कैसे डेटाबेस के साथ इंटरैक्ट करता है।

हालाँकि, किसी अन्य प्रोजेक्ट में मैंने डेटाबेस को गैर-जेनेरिक रिपॉजिटरी पैटर्न में एक्सेस किया है, और मेरे रिपॉजिटरी के गेट * तरीके डेटाबेस पर चल रहे प्रश्नों के लिए पूरी तरह से जिम्मेदार हैं, और वे वास्तविक ऑब्जेक्ट्स ( IQueryable<T>एस नहीं ) लौटाते हैं । इस उदाहरण में, रिपॉजिटरी तरीके DB संस्थाओं को POCO संस्थाओं में परिवर्तित कर रहे हैं और इस मामले में CodeFirst आपको उतना लाभ नहीं प्रदान करता है जितना कि CodeFirst POCOs को कम समय के लिए रहते हैं और जल्दी से व्यवसायिक परत # वर्ग में परिवर्तित हो जाते हैं।

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

Answer 3

कोड प्रथम बड़े पैमाने के अनुप्रयोगों के लिए उपयुक्त नहीं है। बड़े पैमाने पर ऐप डेवलपमेंट टर्नअराउंड बहुत बड़ा है।

आमतौर पर आपके व्यवसाय एप्लिकेशन का जीवन चक्र ऐसा होता है,

1. संस्करण 1 उत्पादन में है
2. संस्करण 2 बीटा में है
3. संस्करण 3 सक्रिय विकास में है
4. संस्करण 4 योजना में है।

और अन्य क्रॉस एप्लिकेशन संचार पुल, कुछ अनुसूचित कार्य, कुछ तृतीय पक्ष एकीकरण, कुछ अलग संचार उपकरणों जैसे मोबाइल आदि के लिए वेब सेवाएं हैं।

आखिरकार कोड पहले एंटिटी मॉडल के ऑब्जेक्ट कॉन्टेक्स्ट का उपयोग करता है, पुराने EF EDMX का निर्माण करता है और EntityObject के साथ ObjectContext का उपयोग करना वास्तव में सब कुछ के लिए पर्याप्त था। आप कोड जनरेट करने के लिए टेक्स्ट टेम्प्लेट को आसानी से कस्टमाइज़ कर सकते हैं। पता परिवर्तन विधि ObjectContext कार्यान्वयन के साथ धीमी है, लेकिन प्रॉक्सी उत्पन्न करने के बजाय, EF टीम आसानी से पहले कोड को पुनः प्राप्त करने के बजाय पता परिवर्तन की गति में सुधार कर सकती थी।

स्वचालित प्रवासन

स्वचालित प्रवासन सिद्धांत में अच्छा लगता है, लेकिन अभ्यास में एक बार जब आप लाइव जाते हैं तो असंभव है। यह केवल प्रोटोटाइप के लिए अच्छा है, कुछ त्वरित डेमो विकसित करना।

इस तरह की प्रणाली में कोड फर्स्ट माइग्रेशन बिल्कुल भी उपयुक्त नहीं है। संस्करण 1 और संस्करण 2 सबसे अधिक संभावना एक ही डेटाबेस से बात करते हैं। संस्करण 3 और संस्करण 4 आमतौर पर मंचन होता है और इसमें अलग-अलग डेटाबेस होते हैं।

डेटाबेस पहले

डेटाबेस फर्स्ट व्यावहारिक दृष्टिकोण है, एसक्यूएल लिपियों की तुलना और कल्पना करना और उन्हें बनाए रखना आसान है। डीबीए आसानी से काम कर सकते हैं।

पाठ टेम्पलेट

हमने अपने स्वयं के टेक्स्ट टेम्प्लेट को क्वेरी करने और ईडीएमएक्स और ऑब्जेक्ट कॉन्टेक्स्ट बनाने के लिए थोड़ा कस्टम कार्यान्वयन के साथ प्रदर्शन के मुद्दों को संबोधित किया। किसी भी समस्या के बिना एक ही डेटाबेस से संवाद करने वाले कई संस्करणों के साथ कई अनुप्रयोग हैं।

मेरे लिए, .tt फ़ाइल पर राइट क्लिक करना और "रन कस्टम टूल" पर क्लिक करना सबसे तेज़ और आसान कदम है, फिर कक्षाएं लिखना, कॉन्फ़िगर करना और मॉडल बनाना।

Comments

आपके द्वारा वर्णित परिदृश्य के लिए माइग्रेशन सटीक रूप से लक्षित हैं।

— केसी

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

— केसी

@ कैसी यह एक बड़ा IF है, जब एक एप्लीकेशन के जीवनकाल पर विचार किया जाता है :)

— BVernon

Answer 4

आमतौर पर बड़ी परियोजनाओं के लिए डेटाबेस पहले ही बनाया जा चुका है। या तो क्योंकि यह एक विरासत डेटाबेस है या प्रदर्शन के लिए एक सक्षम डीबीए द्वारा बनाया गया है। CodeFirst से एकमात्र लाभ यह है कि यदि आप EF की संस्थाओं का उपयोग नहीं करना चाहते हैं, लेकिन इसके बजाय POCOs।

Answer 5

यह मुझे लगता है कि "कोड फर्स्ट" ईएफ का उपयोग अधिक "फुर्तीली" के साथ करने के लिए है (उस शब्द पर बहुत ज्यादा वीणा न करें, मुझे जरूरी नहीं कि कार्यप्रणाली का मतलब है) और ग्रीनफील्ड एप्लिकेशन, जहां आपके पास नहीं है मौजूदा डेटा मॉडल या मौजूदा डेटा; जिस तरह का ऐप आप Django, या PHP फ्रेमवर्क का उपयोग कर सकते हैं, या उन फ्रेमवर्क के दिशानिर्देशों का पालन करने के लिए रेल, जो आमतौर पर डेटा मॉडल के आसपास एक एप्लिकेशन बनाने के बजाय कोड के हिस्से के रूप में डेटा मॉडल का निर्माण करते हैं, जो पारंपरिक है चीजों को संभालने का Microsoft तरीका।

तो सवाल का जवाब देने के लिए मैं कहूंगा कि नहीं; यदि आपके पास पहले से मौजूद डेटा है और आप इसे संभालने के लिए एक एप्लिकेशन बना रहे हैं, तो कोड फर्स्ट का उतना अर्थ नहीं है। हालाँकि, और मैंने EF का बहुत अधिक उपयोग नहीं किया है, अकेले ही पहले First EF का उपयोग करें, ऐसा लगता है कि यह कोड के लिए एक अधिक शिथिल-युग्मित दृष्टिकोण है जो हमेशा फायदेमंद होता है। यह मानते हुए कि आप कोड फर्स्ट का उपयोग कर सकते हैं और तब भी क्लास को एक मौजूदा डेटा मॉडल (मॉडल को जेनरेट करने के लिए मजबूर करने के बजाय) को इंगित कर सकते हैं। इकाई ढाँचा (यानी उत्पन्न मेटाक्लासेस)।

Comments

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

— मोना

Answer 6

मैं वास्तव में बड़ी परियोजनाओं में कहूंगा, कोड-प्रथम का कोई मतलब नहीं है।

वास्तव में, जब परियोजना वास्तव में बड़ी हो जाती है, तो आपको अक्सर चिंताओं का सख्त अलगाव होता है। आपके पास C # कोड लिखने, डेटाबेस डिज़ाइन करने, HTML / CSS लिखने और फ़ोटोशॉप में विज़ुअल डिज़ाइन करने का समान व्यक्ति नहीं हो सकता है। इसके बजाय, डेटाबेस डिज़ाइन डेटाबेस प्रशासक द्वारा किया जाता है (या कम से कम एक समर्पित व्यक्ति जो उसे नौकरी जानता है)।

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

इसके अलावा, मुझे यकीन नहीं है कि अगर डेटाबेस को ठीक से डिजाइन करने के लिए एंटिटी फ्रेमवर्क पर्याप्त शक्तिशाली है। इंडेक्स के बारे में क्या? प्रतिबन्ध? दृश्य?

Comments

हाय, हाँ, यही मैंने सोचा था। मुझे लगता है कि मुझे लगता है कि यह साफ-सुथरा है, लेकिन मुझे वास्तव में इसे करने का कोई फायदा नहीं दिखता है कि मैं कैसे करता था, जो पहले डेटाबेस को डिजाइन करना था। मैं सिर्फ यह सुनिश्चित करना चाहता था कि ऐसा न हो क्योंकि मैं कुछ समझ नहीं पाया था।

— रोबोशॉप

हमने अपनी, बहुत बड़ी, परियोजना के लिए एक विस्तार पुस्तकालय जोड़ा, जो हमें कोड-प्रथम संस्थाओं पर अनुक्रमणिका को एनोटेट करने की अनुमति देता है - महान काम करता है और बनाने में अपेक्षाकृत आसान था।

— कैस्पर

Answer 7

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