मुझे एलोक्वेंट ओआरएम से नफरत क्यों है

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

मुझे गूंगा कोड पसंद है। गूंगे इस अर्थ में कि 10 साल बाद भी, यदि ग्राहक आपसे इसमें बदलाव करने के लिए कहता है, तो आप इसे पूरे तर्क के बिना, शुक्रवार को कॉर्पोरेट पार्टी के बाद, पुराने कोड में कुछ भी तोड़कर, बिना किसी देरी के कर सकते हैं। और इस अर्थ में गूंगा कि आपको इसे समझने के लिए कोई संज्ञानात्मक प्रयास करने की आवश्यकता नहीं है। लेकिन लारवेल एलोक्वेंट ओआरएम में एक वास्तुशिल्प समाधान है जो मुझे रोता है। रुचि रखते हैं? बिल्ली के नीचे आओ।

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

ये मुझे लारवेल और सिम्फनी पसंद हैं। वे आपको सबसे सही और सुरक्षित कोड बॉक्स से बाहर लिखने की अनुमति देते हैं। हां। उनमें से प्रत्येक की अपनी कमियां हैं ... लेकिन लारवेल में एक है जो मुझे सबसे अधिक परेशान करता है। यह मॉडल के साथ काम करने के लिए सक्रिय रिकॉर्ड पैटर्न (एआर) का उपयोग कर रहा है।

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

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

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

एआर एक पैटर्न है जो एंटिटी और रिपॉजिटरी को एक मॉडल में मैप करता है। यही है, एक ऑब्जेक्ट डेटाबेस में एक विशेष रिकॉर्ड का प्रतिनिधित्व करता है। और ... क्या? इससे क्या होता है और यह इतना कष्टप्रद क्यों है?

सबसे पहले, हम साझा जिम्मेदारी के एक ही सिद्धांत का उल्लंघन करते हैं - एक स्थान पर भंडार के साथ काम करने का तर्क, और दूसरे में एक इकाई के साथ काम करने का तर्क। यह महत्वपूर्ण है, क्योंकि मेरे सिस्टम के ढांचे में मैं कॉल चेन के माध्यम से ऑब्जेक्ट प्रतिनिधित्व में डेटाबेस से एक पंक्ति स्थानांतरित नहीं करना चाहता हूं। मैं मॉडल पास करना चाहता हूं। मुझे यह बताने की जरूरत नहीं है कि यह कैसे बदल जाता है, बदल जाता है और बना रहता है। मुझे उन तरीकों की आवश्यकता है जो आपको केवल मॉडल के साथ बातचीत करने की अनुमति देते हैं, और डेटाबेस में पंक्तियों के साथ नहीं।

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

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

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

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

हां, नए चिप्स का आविष्कार किया जा रहा है ( ट्रूकॉलर ?), लेकिन चलो चालें चलें। लेकिन फिर भी मैं ढांचे से थोड़ी अधिक स्वतंत्रता चाहता हूं, खासकर जब से यह इतने सारे के लिए बहुत अच्छा है!