क्या ORM एक एंटी-पैटर्न है? [बन्द है]

Question

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

लेकिन मैं इस समय अपने तर्कों को सूचीबद्ध नहीं करना चाहता। तो मैं आपसे पूछता हूं, आप ORM के बारे में क्या सोचते हैं? पेशेवरों और विपक्ष क्या हैं?

Comments

क्या आपने इसे पढ़ा है: seldo.com/weblog/2011/08/11/orm_is_an_antipattern ?

— FrustratedWithFormsDesigner

हाँ। जब तक आपके पास एक सामान्य CRUD एप्लिकेशन नहीं है जो उस डेटाबेस के साथ कुछ भी मूल्य नहीं करता है जिस स्थिति में आप एक रिलेशनल डेटाबेस का उपयोग नहीं करना चाहिए।

— रेयानोस

@derphil: आप इसे कम व्यापक बनाना चाहते हैं, अन्यथा यह बंद हो जाएगा। यदि आपको लगता है कि यह एक विरोधी पैटर्न है, तो शायद यह क्यों और फिर पूछें कि यह किन-किन स्थितियों में उपयुक्त है, (लेकिन यह अभी भी बहुत व्यापक हो सकता है)।

— FrustratedWithFormsDesigner

@derphil, उस ब्लॉग पोस्ट की टिप्पणियों में बहुत सारे प्रतिवाद हैं, क्या आपने उन्हें पढ़ा है?

— Péter Török

और सिर्फ एक और सबूत कि आपको ORM की आवश्यकता क्यों नहीं है: medium.com/@wrong.about/you-dont-need-an-orm-7ef83bd1b37d

— Zapadlo

Answer 1

ऑब्जेक्ट ओरिएंटेड एंगल से किसी रिलेशनल डेटाबेस को एप्रोच करने के लिए वैचारिक और तकनीकी कठिनाइयों का एक बहुत बड़ा और विविध सेट है। इन कठिनाइयों को सामूहिक रूप से ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल के रूप में जाना जाता है और संबंधित विकिपीडिया लेख अत्यंत जानकारीपूर्ण है। लेख काफी कुछ पहचानता है, मैं उन्हें यहाँ वर्णन करने का कोई समझदार तरीका नहीं देखता। बस आपको एक सामान्य विचार देने के लिए, उन्हें इस प्रकार सूचीबद्ध किया गया है:

• बेमेल
  • वस्तु-उन्मुख अवधारणाएं
  • डेटा प्रकार के अंतर
  • संरचनात्मक और अखंडता अंतर
  • जोड़ तोड़ के अंतर
  • लेन-देन का अंतर
• प्रतिबाधा बेमेल को हल करना
  • न्यूनतम
  • वैकल्पिक आर्किटेक्चर
  • नुकसान भरपाई
• विवाद
• दार्शनिक अंतर

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

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

लेकिन क्या यह उपयोगी है? हाँ ORM वहाँ से बाहर सबसे उपयोगी विरोधी पैटर्न में से एक है। आप समझेंगे कि केवल तभी जब आप खुद को एक व्यावहारिक स्थिति में पाते हैं जहां आपको एक परियोजना में डेटाबेस स्वैप करना होगा। या यहां तक ​​कि एक ही डेटाबेस के दूसरे संस्करण में अपग्रेड करें। ORM उन चीजों में से एक है, जिन्हें आप केवल तभी पूरी तरह से समझ पाते हैं जब आपको वास्तव में उनकी आवश्यकता होती है।

बेशक, सब कुछ उपयोगी के रूप में, ओआरएम दुरुपयोग के लिए अत्यधिक संभावना है। यदि आपको लगता है कि यह किसी भी तरह से डेटाबेस पर आपके द्वारा काम करने के बारे में सब कुछ जानने की आवश्यकता को बदल देता है, तो यह वापस आ जाएगा और आपको काट देगा। कठिन।

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

Comments

वाक्यांश "प्रतिबाधा बेमेल" में काम करने के लिए +1। Geeks के लिए Buzzwords, लेकिन मैं उन्हें भी पसंद करता हूँ!

— हार्डमैथ

पूरी तरह से सहमत ... इस लिंक की जाँच करें तो बहुत अच्छी तरह से समझाया गया है: seldo.com/weblog/2011/08/11/orm_is_an_antipattern

— sandino

Answer 2

यह पूछने के लिए समान है "क्या एक पावर ड्रिल एक एंटी-पैटर्न है?"। ORMs ने मेरे टूलबॉक्स में एक अच्छी जगह अर्जित की, मेरे बॉयलरप्लेट कोड को कम किया और यदि आवश्यक हो तो मैं अभी भी कस्टम SQL का उपयोग करने में सक्षम हूं। तो अगर यह एक विरोधी पैटर्न है, तो यह किस पैटर्न के खिलाफ जाता है?

मेरा जवाब नहीं है, वहाँ बहुत सारे परिपक्व ओआरएम हैं जो आपके जीवन को बहुत आसान बनाते हैं और आपके कोड को अधिक समझने योग्य बनाते हैं। यह किसी भी तरह से मतलब है कि आपको एसक्यूएल को समझने की आवश्यकता नहीं है, इसके विपरीत।

Comments

+1 मुझे भी लगता है कि यह बहुत उपयोगी है, एक सीखने की अवस्था है। लेकिन यह बहुत अच्छा नहीं है कि मैन्युअल रूप से पोज़ोस, आदि को पॉप्युलेट करें

— निमशिम्प्सकी

Answer 3

मैं कुछ "एंटी-पैटर्न" कहने के लिए उत्सुक हूं, जिसे पहले मार्टिन फाउलर द्वारा एक पैटर्न कहा जाता था और तब से लगभग हर आधुनिक प्रोग्रामिंग भाषा में गले लगाया गया है। ( ActiveRecord पर विकिपीडिया लेख देखें ।)

एक अच्छा ओआरएम एक परियोजना में बहुत कम कोड (और बहुत कम पुनरावृत्ति) को जन्म दे सकता है, और कुछ भी नहीं है क्योंकि मूल कोड की मात्रा के रूप में कीड़े के साथ दृढ़ता से सहसंबद्ध है।

ORM आमतौर पर डेटाबेस के साथ काम करने के लिए सबसे आम उपयोग के मामलों को संभालने के लिए डिज़ाइन किए गए हैं। जटिल प्रश्नों को अभी भी स्पष्ट रूप से लिखे जाने की आवश्यकता हो सकती है। लेकिन मैं दृढ़ता से हर डेटाबेस इंटरैक्शन के लिए स्पष्ट प्रश्न लिखने को विस्थापित करूंगा। ज्यादातर मामलों में, यह समय की बर्बादी है।

Comments

"मैं अधिकार से तर्क के खिलाफ जाने में संकोच करूंगा"

— रेयोनोस नोव

@ रेयानोस: आपका मतलब ... आप कह रहे हैं ... फाउलर हो सकता है .... गलत है?!? झटका और हांफना! ईश - निंदा!! : पी;)

— फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर

@ रेयानोस - शायद प्राधिकरण सबसे अच्छा तर्क नहीं है, लेकिन ओपी ने कहा "मेरे अनुभव में"। यह अनिवार्य रूप से व्यक्तिगत प्राधिकरण के लिए एक अपील है, इसलिए मुझे लगता है कि प्राधिकरण और आम सहमति की अपील के साथ मुकाबला करना उचित है। इसके अलावा, शब्द "एंटी-पैटर्न" खुद राय के बारे में है। मैंने अन्य लोगों के बारे में क्या सोचा है, इसके उदाहरण दिए हैं।

— नाथन लॉन्ग

@ नथानलॉन्ग मैं सिर्फ इशारा कर रहा था कि लोकप्रियता और सही-नेस का ओर्थोगोनल है।

— रेयानोस

एफडब्ल्यूआईडब्ल्यू डाटा मैपर संभवतः एक पैटर्न है जो ओआरएम के सबसे अधिक निकटता से मैप करता है। ActiveRecord एक अलग पैटर्न है, हालांकि निश्चित रूप से संबंधित है।

— जेसनट्र्यू

Answer 4

SQL सीखने के बजाय ORM का उपयोग करना एक बहुत बुरा विचार है। यदि आपको पता नहीं है कि एसक्यूएल किस तरह से उत्पन्न हो रहा है, यदि आप एन + 1 समस्याओं को नहीं समझते हैं और कैसे अनुकूलन करते हैं तो यह निश्चित रूप से अच्छे से अधिक नुकसान का कारण होगा। हालांकि मुझे लगता है, कि मैं एक ORM का उपयोग करके बहुत अधिक उत्पादक हूं। मैं रेल्स एक्टिव को पसंद करता हूं, जो यह ढोंग करने की कोशिश नहीं करता है कि कोई डेटाबेस नहीं है और अगर आपको एसक्यूएल लिखने की जरूरत है तो आपके रास्ते में नहीं आती है। हालांकि मुझे चिंता है कि कुछ लोग उन मुहावरों पर भरोसा कर सकते हैं जिन्हें वे बहुत गहराई से देखते हैं, वे क्या कर रहे हैं, इसकी गहरी समझ के बिना।

Answer 5

मेरा अनुभव: मैं NHibernate का उपयोग Linq2NHibernate के साथ कर रहा हूँ।

पेशेवरों:

• यह "मैजिक स्ट्रिंग्स" से छुटकारा दिलाता है, या कम से कम एक बार और केवल-एक बार उन्हें लगाने के लिए जगह प्रदान करता है
• यह मुझे पूरे समय एक OO प्रतिमान में काम करने की अनुमति देता है
• कोड को पढ़ना आसान है
• शीर्ष पर बनाया गया कोड बदलना आसान है
• यह आपको 2 अलग-अलग रिपॉजिटरी (शायद ही कभी किया जाता है, लेकिन यह एक बड़ा लाभ है अगर आपको इसकी आवश्यकता है) के बिना अपने वास्तविक संबंधपरक डेटाबेस को स्वैप करने की अनुमति देता है।

विपक्ष:

• कोड लिखना कठिन है , क्योंकि
• यह एक पर्याप्त अमूर्तता नहीं है - आपको अभी भी पृष्ठभूमि में क्या कर रहा है, इसके साथ अंतरंग रूप से परिचित होना है

मैं कहूंगा कि यह उस वादे पर खरा नहीं उतरता है, जो ज्यादातर लोग शुरू में उम्मीद करते हैं। मैं किसी को यह कहने के लिए दोष नहीं दूंगा कि यह एक विरोधी पैटर्न है। मुझे लगता है कि मेरे मामले में, मुझे अभी भी एक SQLite डेटाबेस के खिलाफ एकीकरण परीक्षण करने की आवश्यकता है ताकि यह सुनिश्चित किया जा सके कि मेरे Linq2NHibernate क्वेरी वास्तव में काम करती हैं। तो वास्तव में, यदि आप किसी वास्तविक रिलेशनल डेटाबेस के खिलाफ किसी भी तरह एकीकरण परीक्षण कर रहे हैं, तो उस तरह की समस्या "जादू के तार" के साथ समाप्त हो जाती है।

अगर मैं एक नई परियोजना शुरू करता, तो मुझे यकीन नहीं होता कि मैं ORM का उपयोग करता या नहीं। मैं शायद होगा, लेकिन मुझे यकीन है कि आप चाहिए के लिए नहीं कह सकता । मैं कहूंगा कि यह आपकी परियोजना के लिए C ++ या Java / .NET को चुनने के बीच अंतर की तरह है: क्या आप को निचले स्तर पर काम करने के साथ लचीलेपन की आवश्यकता है, या आप उच्च स्तर पर काम करेंगे और (माना जाता है) अधिक होगा उत्पादक? सामान्य उत्तर के रूप में आप के साथ दूर कर सकते हैं के रूप में उच्च स्तर पर काम करने के लिए है । आमतौर पर इसका मतलब है कि ORM का उपयोग करना।

Answer 6

एक ORM की ताकत यह है कि यह आपको ऑब्जेक्ट-ओरिएंटेड तकनीकों का उपयोग करके एप्लिकेशन व्यवहार को मॉडल करने की अनुमति देता है। ध्यान से इंजीनियर की दुनिया में, आपके पास एप्लिकेशन की एक परत है जहां व्यवसाय की भाषा बड़े करीने से विकास टीम की भाषा से मिलती है। ORM उस का एक प्रवर्तक है, यदि ORM का उपयोग समझदारी से किया जाता है।

कमजोरी यह है कि वास्तव में वास्तव में वस्तु-उन्मुख प्रोग्रामिंग प्राप्त करने वाले लोगों की संख्या बहुत कम है। बहुत से लोग स्पेगेटी और मीटबॉल लिखते हैं, जिनमें बहुत अधिक युग्मित वस्तुएं होती हैं, जिनमें उनका स्वयं का व्यवहार बहुत कम होता है और वास्तव में व्यवहार behavior०००-पंक्ति "सेवा" और "प्रबंधक" कक्षाओं में समाप्त होता है, और यह कोड अक्सर इतना जटिल होता है कि हर कोई डर जाता है। इसे बदलने के कारण वे यह पता नहीं लगा सकते हैं कि दुष्प्रभाव क्या होगा।

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

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

ORM आपको अधिक स्मार्ट नहीं बनाएंगे, लेकिन सही डेवलपर के हाथों में, अधिक रख-रखाव और उच्च-गुणवत्ता वाला कोड हो सकता है।

Comments

मुझे लगता है कि यह डीबी पहुंच के लिए एक पैटर्न के रूप में ओआरएम और डीबी पहुंच को आसान और बेहतर बनाने के लिए एक फैंसी कोड-जनरेटर के रूप में ओआरएम का उपयोग करता है।

— gbjbaanb

मुझे यकीन नहीं है कि आप इसका क्या मतलब है। आपकी टिप्पणी मेरे लिए बहुत मायने नहीं रखती है।

— जेसनट्र्यू

इसमें एक ORM आपके लिए की गई एक टन की मेहनत के साथ DB को एक्सेस करने का एक शानदार तरीका बनाता है, लेकिन अगर आप इसका उपयोग किसी डीबी का ढोंग करने के लिए एक डिज़ाइन पैटर्न के रूप में करते हैं, तो यह वस्तुओं का एक संग्रह है, यह खत्म होने लगता है। जो मुझे लगा कि आप कह रहे हैं।

— gbjbaanb

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

— जेसनट्र्यू

Answer 7

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

मुझे लगता है कि जब आप एक की जरूरत नहीं है यहाँ वास्तविक विरोधी पैटर्न एक संबंधपरक DB का उपयोग कर सकते हैं। यदि आपको एक की आवश्यकता है, तो आपको ORM की आवश्यकता है, और यह निश्चित रूप से एक विरोधी पैटर्न नहीं है।

Comments

जब मैं मानता हूँ कि संबंधपरक डेटाबेस का उपयोग करना यदि आपको किसी की आवश्यकता नहीं है, तो यह एक बुरा विचार है, कि यदि आप एक का उपयोग करते हैं, तो आपको एक ORM की आवश्यकता होती है जो कि बहुत ही अजीब है!

— HLGEM

उम, फिर आप अपना डेटा डेटाबेस में और बाहर कैसे प्राप्त करेंगे? कहीं न कहीं, कुछ को अपनी वस्तुओं को संबंधपरक संरचना में मैप करना होगा, और डेटाबेस से पढ़ने के बाद उन्हें फिर से बनाना होगा। यहां तक ​​कि अगर आप प्रश्नों को हाथ से लिखते हैं और डेटा को परिणाम सेट से बाहर कॉपी करते हैं, तो आप ORM कर रहे हैं।

— TMN

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

— HLGEM

@ एचएलजीईएम: और उस डेटा के बारे में जो आप डेटाबेस से बाहर निकलते हैं? जब आप रिलेशनल डेटाबेस को क्वेरी करते हैं, तो क्या आप वस्तुओं के परिणामों को मैप नहीं करते हैं? मेरे अनुभव में, दो प्रकार के प्रोजेक्ट हैं जो रिलेशनल डेटाबेस का उपयोग करते हैं: वे जो थर्ड-पार्टी ओआरएम का उपयोग करते हैं, और वे जो अपने स्वयं के खराब-निर्मित ओआरएम को शामिल करते हैं।

— कार्सन 63000

+1 कार्सन। आप किसी भी तरह के ORM का उपयोग करते हैं, जब तक आप केवल कच्चे डेटासेट वापस नहीं करते हैं और अपने कोड (उन सभी IMHO का सबसे अधिक अपमानजनक) पर प्लास्टर करते हैं, क्योंकि आपको हमेशा उस संग्रहीत प्रक्रिया के परिणामों को कक्षाओं में मैप करना होगा, जो वास्तव में है ORM आपके लिए करते हैं।

— वेन मोलिना

Answer 8

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

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