EntityFramework का उपयोग करके कुछ तर्क क्या हैं? [बन्द है]

31

वर्तमान में मैं जो एप्लिकेशन बना रहा हूं वह डेटाबेस ऑब्जेक्ट्स का प्रतिनिधित्व करने के लिए संग्रहीत प्रक्रियाओं और हाथ से तैयार किए गए क्लास मॉडल का उपयोग कर रहा है। कुछ लोगों ने एंटिटी फ्रेमवर्क का उपयोग करने का सुझाव दिया है और मैं उस पर स्विच करने पर विचार कर रहा हूं क्योंकि मैं उस परियोजना में नहीं हूं। मेरी समस्या यह है, मुझे लगता है कि EF के लिए बहस करने वाले लोग मुझे केवल चीजों का अच्छा पक्ष बता रहे हैं, बुरे पक्ष को नहीं :)

मेरी मुख्य चिंताएं हैं:

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

EF के लिए तर्क हैं:

संगामिति। मुझे यह देखने के लिए चेक में कोड नहीं करना होगा कि क्या प्रत्येक सेव से पहले रिकॉर्ड अपडेट किया गया था
कोड जनरेशन। EF मेरे लिए आंशिक वर्ग मॉडल और POCO उत्पन्न कर सकता है, हालाँकि मैं सकारात्मक नहीं हूँ यह वास्तव में मुझे उस समय को बचाएगा क्योंकि मुझे लगता है कि हमें अभी भी सत्यापन और कुछ कस्टम पार्सिंग विधियों के लिए क्लाइंट-साइड मॉडल बनाने की आवश्यकता होगी।
विकास की गति चूंकि हमें हर डेटाबेस ऑब्जेक्ट के लिए CRUD संग्रहीत कार्यविधियाँ बनाने की आवश्यकता नहीं होगी

हमारी वर्तमान वास्तुकला में WPF सेवा शामिल है, जो डेटाबेस कॉल को मानकीकृत संग्रहीत कार्यविधियों, POCO ऑब्जेक्ट्स के माध्यम से संभालती है, जो WCF सेवा और WPF क्लाइंट से / के पास जाते हैं, और WPF डेस्कटॉप क्लाइंट स्वयं जो POCO को वर्ग मॉडल में रूपांतर के उद्देश्य से रूपांतरित करता है और अनिवार्य तथ्य।

तो मेरा सवाल यह है कि क्या इसके लिए ईएफ सही है? क्या ईएफ के बारे में कोई ऐसी गड़बड़ी है जिससे मैं अनजान हूं?

architecture orm entity-framework

— राहेल
स्रोत

इसे भी देखें .. प्रदर्शन और LINQ समर्थन की तुलना: ormeter.net

— M.Sameer

7

मैं हाल ही में एंटिटी फ्रेमवर्क का मूल्यांकन कर रहा था और मुझे सबसे अच्छी जगह जो मुद्दों और गुम विशेषताओं के लिए मिली थी, वह थी: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

अधिकांश वोटों के साथ आइटम:

Enums के लिए समर्थन। यह एक बहुत बड़ा है, लेकिन वर्तमान में कुछ वर्कअराउंड हैं
बेहतर SQL पीढ़ी। विशेष रूप से एंटरप्राइज़ स्तर के अनुप्रयोगों के लिए गति वास्तव में महत्वपूर्ण है, लेकिन ऐसा लगता है कि ईएफ 4 के साथ इसमें बहुत सुधार हुआ है
कई डेटाबेस के लिए समर्थन। किसी भी बड़े आवेदन के लिए आवश्यकता।

उपयोगकर्ता वॉयस सूची में कई और मुद्दे हैं।

एक साइड नोट पर, मैं EF 4.1 की आगामी रिलीज़ के बारे में बहुत उत्साहित हूं जिसमें कोड-प्रथम दृष्टिकोण शामिल होगा ... http://blogs.msdn.com/b/adonet/archive/2011/03/03/15/ef-4 -1 रिलीज उम्मीदवार-available.aspx

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

— Mag20
स्रोत

इसके विरुद्ध तर्क: पहला और दूसरा और तीसरा: यह धीमा है !!! लर्निंग कर्व है (लेफ्ट जॉइन कैसे करना है, यह जानने की जरूरत है - एक तरीका खोजने में 3 घंटे लगते हैं, ताकि किसी दूसरे व्यक्ति को पता चले कि क्या किया जा रहा है ...), SQL के बजाय LINQ में पेजिंग (जैसे feches) 10 सैन्य पंक्तियों, फिर उनमें से 20 को एक मनमाना ऑफसेट से लेता है, और फिर आपको आश्चर्य होता है कि यह इतना धीमा क्यों है) ... रेपो गैर-चलने वाला सुरक्षित है, आपको इसे प्रति क्वेरी के आधार पर प्राप्त करना है, और रेपो आरंभीकरण है बहुत कम (5 सेकंड की तरह) यदि आपके पास एक बड़ा डेटाबेस है (जिसका अर्थ है 100-200 टेबल, वास्तव में बड़ी नहीं है)।

— Quandary

2

जैसे आपके LINQ एक्सप्रेशन्स पूरी तरह से परिभाषित होने से पहले आप जैसे IQueryables (यानी कॉलिंग .ToList()या .ToArray) निष्पादित कर रहे हैं, ऐसा लगता है। इसलिए यह सभी रिकॉर्ड को खींचता है और इसे धीमा करता है।

— orad

6

ईएफ के साथ शाखा-प्रति-बग / सुविधा मर्ज समय पर उल्लेखनीय रूप से दर्दनाक हो सकती है। कल्पना करें कि दो शाखाएँ A और B डेटाबेस में परिवर्तन करती हैं (जो कि एक नई परियोजना के शुरुआती चरणों के दौरान बहुत कुछ होगा)।

आप सभी "सामान्य" फाइलों - सीएस फाइलों आदि को मर्ज कर देते हैं और फिर मॉडल.डेडएमएक्स को मर्ज करने का समय आ जाता है। और अचानक आप अपने ऑब्जेक्ट मॉडल और डेटाबेस के बीच तार्किक मैपिंग को न केवल विलय कर रहे हैं, बल्कि इकाई आरेख में तालिकाओं की स्थिति भी।

Model.edmx को मिलाना इतना दर्दनाक है कि हमने एक बहुत बुरा तरीका अपनाया है:

मर्ज के दौरान, बस एक माता-पिता से सभी मर्ज का चयन करें। जो मायने नहीं रखता; आप वैसे भी फ़ाइल को जल्द ही टोस्ट कर लेंगे:
या तो माता-पिता के लिए Model.edmx को वापस लाएं।
अपने डेटाबेस को नए मर्ज किए गए राज्य में माइग्रेट करें।
Model.edmx, और "डेटाबेस से मॉडल अपडेट करें" खोलें।
मर्ज के दौरान बर्बाद किए गए सभी नेविगेशन गुणों का नाम बदलें।

— फ्रैंक शीयर
स्रोत

1

यह आलोचना EF कोड फर्स्ट के लिए मान्य नहीं है, लेकिन मॉडल फर्स्ट और डेटाबेस फर्स्ट पर लागू होती है।

— एलन मैकडोनाल्ड

मैं फ्लुएंट का उपयोग करते हुए सभी मैपिंग बनाता हूं और मैपिंग का पूरा नियंत्रण लेता हूं। इन्हें एक .cs फ़ाइल के अंदर रखा गया है।

— स्टीवन रिससर्ट

5

EF के कुछ अन्य लाभ हैं जो आप गायब हैं:

आपके पास एंटिटी स्पैन टेबल हो सकते हैं
आप एक तालिका को कई प्रकार की संस्थाओं में विभाजित कर सकते हैं
आप डेटाबेस से एंटिटी उत्पन्न कर सकते हैं (यानी मास्टर दृष्टिकोण के रूप में डेटाबेस)
आप डेटाबेस को निकाय से उत्पन्न कर सकते हैं (अर्थात मास्टर दृष्टिकोण के रूप में कोड)
LINQ क्वेरीज़ को SQL क्वेरीज़ में अनुवादित किया जाता है, जिससे उनके प्रदर्शन में सुधार होता है।

चढ़ाव (विशेषकर यदि आप सत्यापन का उपयोग कर रहे हैं):

आपको एक [मेटाडेटाक्लास] विशेषता बनानी होगी जो किसी अन्य वर्ग की ओर इशारा करती है, जिसमें वे गुण हैं जो आप उचित वैध विशेषताओं के साथ मान्य करना चाहते हैं। सभी गुण objectप्रकार हैं, इसलिए मेटाडेटा पढ़ना बस वहीं है। अभी भी बहुत सारे अतिरिक्त निष्क्रिय कोड।
EntityFramework का उपयोग करना एक अलग अवधारणा है जिस तरह से NHibernate (और मूल जावा संस्करण) के साथ कुछ काम करने के लिए डिज़ाइन किया गया है। EntityFramework एक संलग्न मोड में सबसे अच्छा करता है जहाँ ऑब्जेक्ट हर समय लाइव कनेक्शन का उपयोग कर रहे हैं। NHibernate और इसी तरह के ORM उपकरण अलग-अलग मोड में सबसे अच्छा काम करते हैं, जहां कनेक्शन केवल डेटा लोड / सेव करते समय उपयोग किया जाता है।

मेरे पास दो सबसे बड़ी शिकायतें हैं। कई लाभ हैं, लेकिन आप बहुत अच्छी तरह से NHibernate से उन्हीं लाभों को प्राप्त करने में सक्षम हो सकते हैं। यदि EntityFramework टेबल पर है, तो टीम ने NHibernate को भी देखें और अपनी परियोजना के लिए पेशेवरों / विपक्षों के लिए त्वरित शूट करें ।

मेटाडेटा श्रेणी की समस्या एक सिरदर्द है, लेकिन शुक्र है कि मेरे पास केवल इतनी सारी संस्थाएँ हैं जिन्हें सत्यापन टैग की आवश्यकता है।

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

— बेरिन लोरिट्श
स्रोत

आपके तथाकथित कोड को मास्टर दृष्टिकोण के रूप में आधिकारिक तौर पर कोड

— रॉबर्ट कोरिटनिक

1

@Berin, मैं स्पष्ट करना चाहता हूं कि "संलग्न मोड" से आपका क्या मतलब है। मुझे नहीं लगता कि एंटिटी फ्रेमवर्क का डेटाबेस से हर समय खुला संबंध है। मेरा मानना है कि EF इस संबंध में NHibernate के समान काम करता है। क्या आपका यही मतलब है या आपका मतलब कुछ और है? क्या आपके पास दस्तावेज़ीकरण की एक कड़ी है जो इस संलग्न मुद्दे को आगे बताती है?

— रेशनलगीक

1

द्वारा संलग्न, मैं वस्तुओं के साथ अपने सभी बातचीत मतलब होनी चाहिए भीतरusing(EFConnection conn = new EFConnection) निर्माण। यदि आप सुरक्षित रखने के लिए उस वस्तु को कहीं छिपाने की कोशिश करते हैं ताकि आप एक त्वरित अपडेट कर सकें और इसे एक दूसरे using(...)विवरण में फिर से सहेज सकें , तो आपको फिर से सोचना होगा। Msdn.microsoft.com/en-us/library/bb896271.aspx और msdn.microsoft.com/en-us/library/bb896248.aspx देखें । ईएफ 3.5 का उपयोग करना (जो मुझे पिछले संस्करण पर उपयोग करना था) वह भी साफ नहीं है।

— बेरिन लोरिट्श

ठीक है मुझे वही मिलेगा जो अब आपका मतलब है। मैं सिर्फ यह सुनिश्चित करना चाहता था कि लोग इसका मतलब यह न निकालें कि डेटाबेस से हमेशा जुड़ाव था । आपके पास एक ऑब्जेक्ट संदर्भ होना चाहिए जो "संलग्न" संस्थाओं की स्थिति को बनाए रखता है।

— रेशनलगीक

2

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

— मैट ग्रीर

2

एक बात यह है कि Microsoft बहुत अच्छी नहीं है पिछड़ी ~~तुलनात्मकता~~ , विशेषकर जब नई तकनीकों की बात आती है

विशेष रूप से EF1 (.net 3.5) EF4 (.net 4.0) से बहुत अलग है - अगले संस्करण के लिए भी ऐसा ही हो सकता है।

मैं कुछ समय तक प्रतीक्षा करूंगा और देखूंगा कि प्रौद्योगिकी कैसे परिपक्व होती है।

मतलब समय में, nHibernate का उपयोग करने पर विचार करें - यह समकक्ष नहीं है, लेकिन यह परिपक्व और बेतहाशा उपयोग किया जाता है।

— ओफिर योकटन
स्रोत

1

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

मैं 10 पेज का डायट्रीब लिख सकता था। लेकिन, अगर आप सिर्फ कंपनी एक्स के लिए कुछ थ्रो दूर ऐप लिख रहे हैं .. जो तब देखभाल करते हैं। लेकिन, यदि आप एक सॉफ्टवेयर उत्पाद विकसित कर रहे हैं ... आप बहुत अधिक गुदा होने जा रहे हैं

— user104468
स्रोत

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप इसे बेहतर आकार में संपादित करना चाहेंगे ?

— gnat

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

— सिनास्टेटिक

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

— चोट

0

इसे देखें: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

मुख्य बिंदु हैं:

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

ध्यान दें कि उपरोक्त लिंक EF1 के बारे में बात कर रहा है।

इसके अलावा यह लिंक: http://ormeter.net/ दिखाता है कि प्रदर्शन और LINQ समर्थन में अन्य ORM की तुलना में EF सबसे अच्छा नहीं है।

— M.Sameer
स्रोत

ध्यान रखें कि यह तब पोस्ट किया गया था जब ईएफ 1 अभी भी जारी किया गया था (या संभवतः अभी भी बीटा में है)। ईएफ 4 के साथ आज स्थिति काफी बेहतर है, और बिना किसी विश्वास के उस वोट में उठाए गए कई मुद्दों को हल किया गया है।

— रेशनलगीक

अंतिम बिंदु अभी भी मायने रखता है और बहुत महत्वपूर्ण है।

— M.Sameer

1

पहले EF संस्करण 3.5 था। ईएफ के चार प्रमुख संस्करण जारी नहीं किए गए हैं।

— मैट ग्रीर

3

@ माट जो सही है। लेकिन मौजूदा संस्करण को बाकी .NET 4 संस्करण के साथ संरेखित करने के लिए EF 4 कहा जाता है।

— रेशनलगीक

1

यह वैध है या नहीं, हालांकि लिंक के सारांश को प्रभावित नहीं करना चाहिए। वैध होने पर वोट दिखाएंगे। :)

— एडम लेअर