जब आप रेल्स ब्लॉग और किताबें पढ़ते हैं, या कॉन्फ्रेंस वार्ता देखते हैं, तो आप अपने मॉडल को पतला बनाने के बारे में बहुत कुछ सीखेंगे।
ये तकनीकें बहुत अच्छी हैं, क्योंकि आपके मॉडल होंगे बहुत बड़े या जटिल हो जाएंगे जिन्हें संभालना मुश्किल होगा। लेकिन क्या आप वास्तव में चाहते हैं कि आपके मॉडल केवल पर्सिस्टेंस, एसोसिएशन और वैलिडेशन के लिए जिम्मेदार हों? आप कैसे तय करते हैं कि आपके एक्टिवरेकॉर्ड मॉडल में कितना तर्क रहना चाहिए, वैसे भी?
पतला। लेकिन बहुत पतला नहीं।
एक्टिव रिकॉर्ड एक पैटर्न है जो सबसे अच्छा काम करता है जब आपके मॉडल आपके डेटाबेस स्कीमा से निकटता से मेल खाते हैं। यह इसके लिए डिज़ाइन किया गया है! लेकिन इसका क्या मतलब है?
-
यदि कुछ कोड एक्टिवरेकॉर्ड मॉडेल के दृष्टिकोण से काम करता है, तो यह मॉडल में जा सकता है।
-
यदि कुछ कोड काम करता है जो कई टेबल्स/ऑब्जेक्ट्स तक फैला हुआ है, और जिसका वास्तव में कोई स्पष्ट मालिक नहीं है, तो यह सर्विस ऑब्जेक्ट में जा सकता है।
-
कुछ भी जो विशेषता जैसा है (जैसे एसोसिएशन या अन्य विशेषताओं से गणना की गई विशेषताएं) आपके एक्टिवरेकॉर्ड मॉडल में जाना चाहिए।
-
यदि आपके पास तर्क है जो एक साथ कई मॉडल को सहेजने या अपडेट करने का आयोजन करता है, तो यह एक्टिवमॉडल फॉर्म ऑब्जेक्ट में जाना चाहिए।
-
यदि कोड मुख्य रूप से व्यू में मॉडल को प्रदर्शित या फॉर्मेट करने के लिए है, तो यह रेल्स हेल्पर या प्रेजेंटर में जाना चाहिए।
उन दिशानिर्देशों से परे, आपको उन्हीं नियमों का उपयोग करना चाहिए जिनका उपयोग आप किसी भी क्लास को रिफैक्टर करने के लिए करेंगे जो बहुत बड़ी हो रही है। लेकिन आम तौर पर, आपको अपने एक्टिवरेकॉर्ड मॉडल में कुछ तर्क छोड़ने के बारे में बुरा महसूस नहीं करना चाहिए। उन्हें इसके लिए बनाया गया है!
तो, चूंकि रेल्स ने एक्टिव रिकॉर्ड पैटर्न को चुना, इसलिए आपके मॉडल में कुछ तर्क होना समझ में आता है। लेकिन रेल्स ने उस पैटर्न को कुछ क्लीनर के बजाय क्यों चुना?
रूबी क्या करेगी?
Patterns of Enterprise Application Architecture में, एक्टिव रिकॉर्ड पैटर्न रो डेटा गेटवे और डेटा मैपर के बीच मध्य मैदान रखता है। रो डेटा गेटवे टेबल रो के चारों ओर एक ज्यादातर बेवकूफ ऑब्जेक्ट-ओरिएंटेड रैपर है, जैसे सभी संभावित मॉडल में सबसे पतला। डेटा मैपर्स एक्टिव रिकॉर्ड से अधिक जटिल हैं, और ज्यादातर केवल व्यावसायिक तर्क वाले ऑब्जेक्ट्स और केवल पर्सिस्टेंस तर्क वाले ऑब्जेक्ट्स के बीच परिवर्तित करने के लिए उपयोग किए जाते हैं।
तो, रूबी के संदर्भ में, एक्टिव रिकॉर्ड बिल्कुल सही डिफ़ॉल्ट पैटर्न है।
मैं ऐसा क्यों कहता हूं?
रूबी को प्रोग्रामर्स को खुश करने के लिए डिज़ाइन किया गया है। जब इसे क्लीननेस और सुविधा के बीच ट्रेडऑफ बनाने के लिए मजबूर किया जाता है, तो यह लगभग हमेशा सुविधा चुनता है।
मेरा मतलब है, Array के पब्लिक API में सौ से अधिक मेथड हैं। इसमें एक टन मेथड हैं जो एक दूसरे के सिर्फ एलियास हैं। क्योंकि कुछ डेवलपर्स सिर्फ .detect लिखना .find से पसंद करते हैं।
उस संदर्भ में, यह बहुत मायने रखता है कि रेल्स एक ऐसे पैटर्न को डिफ़ॉल्ट करेगा जो अधिक लचीलेपन या अधिक ऑब्जेक्ट-ओरिएंटेड शुद्धता वाले पैटर्न की तुलना में सुविधाजनक है। यह रूबी तरीका है। और मुझे यह पसंद है।
जब आपको आवश्यकता हो तो आप हमेशा कुछ अधिक लचीले में रिफैक्टर कर सकते हैं। लेकिन फिर, YAGNI।
