क्या हम एक हाइब्रिड संरचना के रूप में रेल ActiveRecord का उपयोग करते हैं, यानी डेटा संरचना + ऑब्जेक्ट?

Question

मैं 4 से अधिक वर्षों तक रेल का उपयोग कर रहा हूं, इसलिए जाहिर है कि मुझे रेल पसंद है और रेलवे की तरह काम करना पसंद है और कभी-कभी मैं अनजाने में अंधेरे पक्ष में पड़ता हूं।

मैंने हाल ही में अंकल बॉब द्वारा स्वच्छ कोड उठाया। मैं अध्याय 6 पर हूं और थोड़ा उलझन में हूं कि क्या हम रेल डेवलपर्स ओओ डिजाइन के बहुत ही मौलिक नियम को तोड़ते हैं, यानी डेमेटर या encapsulation का कानून? डेमेटर के कानून में कहा गया है कि किसी ऑब्जेक्ट को किसी अन्य ऑब्जेक्ट के अंदरूनी हिस्से को नहीं जानना चाहिए और इसे किसी विधि द्वारा लौटाए गए ऑब्जेक्ट्स पर विधियों का आह्वान नहीं करना चाहिए क्योंकि जब आप ऐसा करते हैं तो यह सुझाव देता है कि एक ऑब्जेक्ट अन्य ऑब्जेक्ट के बारे में बहुत कुछ जानता है।

लेकिन अक्सर हम मॉडल से किसी अन्य ऑब्जेक्ट पर विधियों को कॉल करते हैं। उदाहरण के लिए, जब हमारे पास 'एक उपयोगकर्ता से संबंधित आदेश' जैसे संबंध होते हैं। फिर अक्सर हम order.user.name कर रहे हैं या इसे ट्रेन के मलबे की तरह दिखने से रोकने के लिए हमने ऑर्डर करने के लिए एक प्रतिनिधि स्थापित किया है। नाम।

1. क्या यह अभी भी डेमेटर या encapsulation के कानून तोड़ने की तरह नहीं है?

2. दूसरा प्रश्न यह है: ActiveRecord केवल डेटा संरचना या डेटा ट्रांसफर ऑब्जेक्ट है जो डेटाबेस के साथ इंटरफेस करता है?

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

Answer 1

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

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

Answer 2

IMHO जहां यह सब ठीक डिजाइन पैटर्न लेकिन का उपयोग करता है कोई कोड के आठ लाइनों तुम सिर्फ एक खोलने की आवश्यकता याद कर सकते हैं फ़ाइल और इसकी सामग्री पढ़ें।

रेल्स एक्टिव रिकार्ड फ्रेमवर्क मार्टिन फाउलर के Active Record design pattern का कार्यान्वयन है। रेल में सक्रिय रिकॉर्ड्स निश्चित रूप से केवल गूंगा डेटा संरचनाएं या डीटीओ नहीं हैं क्योंकि उनके पास व्यवहार है: वे सत्यापन करते हैं, वे आपको बता सकते हैं कि उनके गुण बदल गए हैं या नहीं और आप स्वतंत्र हैं और वास्तव में encouraged, वहां अपना खुद का व्यवसाय तर्क जोड़ने के लिए ।

आम तौर पर रेल अच्छे अभ्यास को प्रोत्साहित करते हैं उदा। बुरी चीजें कठिन और/या बदसूरत करने के लिए एमवीसी और सिंटेक्टिक सिरका।

Answer 3

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

ActiveRecord के मामले में, अधिकांश एलओडी उल्लंघनों में शामिल वस्तुओं को एक करीबी रिश्ते में एक साथ बंधे हुए हैं। इन वस्तुओं की आंतरिक डेटा संरचना को बदलने से नई संरचना को प्रतिबिंबित करने के लिए डेटाबेस में बदलाव की आवश्यकता होती है।डेटाबेस की सारणी आमतौर पर एक ही डेटाबेस में "बाध्य" होती हैं, जो विदेशी कुंजी बाधाओं के माध्यम से इन "एसोसिएशन" को भी प्रतिबिंबित करती है (या कम से कम प्राथमिक & विदेशी कुंजी)।

इसलिए मैं आम तौर पर अपने एआर ऑब्जेक्ट्स के बीच निम्नलिखित लोड के साथ खुद को चिंता नहीं करता हूं। मुझे पता है कि वे अपनी प्रकृति के कारण एक दूसरे से कड़े बंधे हैं।

दूसरी ओर मैं अधिक दूर वस्तुओं के बीच लोड के बारे में अधिक चिंतित हूं, खासकर जो एमवीसी सीमाओं या किसी अन्य डिज़ाइन डिवाइस को पार करते हैं।

Answer 4

हां, ActiveRecord जानबूझकर encapsulation तोड़ता है। यह रेल की इतनी सीमा नहीं है क्योंकि यह उस पैटर्न की सीमा है जिस पर यह आधारित है। मार्टिन Fowler, ActiveRecord की जिसकी परिभाषा काफी टेम्पलेट का उपयोग किया रेल था, POEAA की ActiveRecord अध्याय में के रूप में ज्यादा कहते हैं:

के खिलाफ सक्रिय रिकार्ड एक और तर्क है तथ्य यह है कि यह जोड़ों वस्तु डिजाइन करने के लिए डेटाबेस डिज़ाइन। इससे प्रोजेक्ट प्रोजेक्ट के रूप में डिज़ाइन करने के लिए इसे और अधिक कठिन बनाता है आगे बढ़ता है।

यह अन्य ढांचे से रेल के common criticism है। फाउलर खुद कहते हैं ActiveRecord मुख्य रूप से प्रयोग की जाने वाली

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

फाउलर जटिल डोमेन तर्क Data Mapper pattern, जो करता है परतों को अलग करने का एक बेहतर काम, बेहतर है के साथ और अधिक गंभीर अनुप्रयोगों के लिए है कि कहने के लिए पर चला जाता है। रेलवे upcoming move to Merb को आम तौर पर रेल के लिए सकारात्मक कदम के रूप में देखा जाता है, क्योंकि मेरब ActiveRecord के अतिरिक्त डेटामैपर पैटर्न का उपयोग करता है।

मुझे यकीन नहीं है कि डेमेटर ActiveRecord के साथ प्राथमिक चिंता है। बल्कि मुझे लगता है कि डेटा और डोमेन परतों के बीच ब्रेकिंग encapsulation अंकल बॉब के Single Responsibility Principle तोड़ता है। मुझे लगता है कि डेमेटर ओपन/क्लोज़ड सिद्धांत का पालन करने का एक विशिष्ट उदाहरण है। लेकिन मुझे लगता है कि इन सभी के पीछे व्यापक विचार समान है: वर्गों को एक चीज करना चाहिए और भविष्य में बदलावों के खिलाफ मजबूत होना चाहिए, जो कुछ डिग्री ActiveRecord नहीं है।