रूबी ऑन रेल्स में महारत हासिल करें: पैटर्न, एंटी-पैटर्न, और सर्वोत्तम अभ्यास

रूबी ऑन रेल्स पैटर्न और एंटी-पैटर्न के बारे में हमारी श्रृंखला में पहले पोस्ट में आपका स्वागत है। प्रत्येक पोस्ट में, हम उन सभी प्रकार के पैटर्न में गहराई से गोता लगाएंगे जिनका सामना आप रेल्स ऐप्स के साथ काम करते समय कर सकते हैं।

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

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

हां, आप एक डिज़ाइनर हैं

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

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

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

डिज़ाइन पैटर्न क्या है?

सॉफ़्टवेयर इंजीनियरिंग में, एक पैटर्न को एक समाधान के रूप में वर्णित किया जाता है जिसे सामान्य समस्या को हल करने के लिए पुन: उपयोग किया जा सकता है। पैटर्न कुछ ऐसा है जिसे सॉफ़्टवेयर इंजीनियरों के बीच एक अच्छी प्रथा माना जाता है। चूंकि सॉफ़्टवेयर इंजीनियर उन्हें सेट करते हैं, वे जल्दी से पैटर्न से उनके विपरीत - एंटी-पैटर्न में जा सकते हैं - लेकिन हम बाद में उस पर पहुंचेंगे।

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

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

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

बहुत बढ़िया, अब जब हम डिज़ाइन और पैटर्न से परिचित या अपने ज्ञान को ताज़ा कर चुके हैं, तो आइए पता करें कि एंटी-पैटर्न क्या हैं।

डिज़ाइन एंटी-पैटर्न क्या है?

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

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

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

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

ये चीजें होती हैं और होती रहेंगी। अच्छे लोग बुरे लोगों में बदल जाते हैं, और इसके विपरीत। लेकिन रूबी और रेल्स इस तस्वीर में कहां फिट होते हैं?

पहले रूबी, फिर रेल्स

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

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

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

एक शुरुआत के रूप में, आपको इसे शुरू से अंत तक पढ़ने की ज़रूरत नहीं है। लेकिन इसे अपनी तरफ रखें ताकि आप जल्दी से परामर्श कर सकें। मैं यह नहीं कह रहा हूं कि आपको अचानक जो कुछ भी कर रहे थे उसे रोक देना चाहिए और पूरी किताब पढ़नी चाहिए, लेकिन समय-समय पर रुकें और रूबी की मूल बातें पर अपने ज्ञान को ताज़ा करें, यह आपके लिए कुछ नए क्षितिज खोल सकता है।

MVC: रेल्स की रोटी और मक्खन

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

• मॉडल डेटा और व्यावसायिक तर्क को संभालता है।
• व्यू डेटा की प्रस्तुति और उपयोगकर्ता इंटरफ़ेस के लिए है।
• कंट्रोलर मॉडल से डेटा प्राप्त करके और उपयोगकर्ता को व्यू दिखाकर दोनों को जोड़ता है।

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

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

लेकिन वहां एंटी-पैटर्न क्या हैं, इतने व्यापक रूप से उपयोग किए जाने वाले पैटर्न में? आइए MVC पैटर्न के प्रत्येक भाग के लिए कुछ सबसे आम एंटी-पैटर्न पर जाएं।

मॉडल समस्याएं

जैसे-जैसे एक एप्लिकेशन बढ़ता है और व्यावसायिक तर्क का विस्तार होता है, लोग अपने मॉडल को ओवरक्राउड करते हैं। निरंतर वृद्धि फैट मॉडल नामक एंटी-पैटर्न का कारण बन सकती है।

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

class Song < ApplicationRecord belongs_to :album belongs_to :artist belongs_to :publisher has_one :text has_many :downloads validates :artist_id, presence: true validates :publisher_id, presence: true after_update :alert_artist_followers after_update :alert_publisher def alert_artist_followers return if unreleased? artist.followers.each { |follower| follower.notify(self) } end def alert_publisher PublisherMailer.song_email(publisher, self).deliver_now end def includes_profanities? text.scan_for_profanities.any? end def user_downloaded?(user) user.library.has_song?(self) end def find_published_from_artist_with_albums ... end def find_published_with_albums ... end def to_wav ... end def to_mp3 ... end def to_flac ... end end

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

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

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

कॉलबैक जो फॉलोअर्स और पब्लिशर को सूचित करते हैं, उन्हें जॉब्स में निकाला जा सकता है। जॉब्स एनक्यू किए जाएंगे और तर्क मॉडल से बाहर रखा जाएगा, जैसे:

class NotifyFollowers < ApplicationJob def perform(followers) followers.each { |follower| follower.notify } end end class NotifyPublisher < ApplicationJob def perform(publisher, song) PublisherMailer.song_email(publisher, self).deliver_now end end

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

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

class SongDecorator < Draper::Decorator delegate_all def includes_profanities? object.text.scan_for_profanities.any? end def user_downloaded?(user) object.user.library.has_song?(self) end end

फिर, आप अपने कंट्रोलर में decorate कॉल करेंगे, उदाहरण के लिए:

def show @song = Song.find(params[:id]).decorate end

और इसे अपने व्यू में इस तरह उपयोग करें:

<%= @song.includes_profanities? %> <%= @song.user_downloaded?(user) %>

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

module SongFinders def find_published_from_artist_with_albums ... end def find_published_with_albums ... end end module SongConverter def to_wav ... end def to_mp3 ... end def to_flac ... end end

Song मॉडल SongFinders मॉड्यूल को एक्सटेंड करेगा, इसलिए इसके मेथड्स क्लास मेथड्स के रूप में उपलब्ध हैं। Song मॉडल SongConverter मॉड्यूल को शामिल करेगा, इसलिए इसके मेथड्स मॉडल इंस्टेंस पर उपलब्ध हैं।

इस सब से हमारा Song मॉडल काफी पतला और मुद्दे पर होना चाहिए:

class Song < ApplicationRecord extend SongFinders include SongConverter belongs_to :album belongs_to :artist belongs_to :publisher has_one :text has_many :downloads validates :artist_id, presence: true validates :publisher_id, presence: true after_update :alert_artist_followers, if: :published? after_update :alert_publisher def alert_artist_followers NotifyFollowers.perform_later(self) end def alert_publisher NotifyPublisher.perform_later(publisher, self) end end

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

व्यू समस्याएं

मॉडल समस्याओं के अलावा, रेल्स लोग कभी-कभी अपने व्यू की जटिलता से संघर्ष कर सकते हैं। पुराने समय में, HTML और CSS वेब एप्लिकेशन के व्यू भाग के राजा थे। धीरे-धीरे समय के साथ, जावास्क्रिप्ट शासन करने आया, और फ्रंट एंड के लगभग सभी पहलू जावास्क्रिप्ट में लिखे गए थे। रेल्स इस संबंध में थोड़ा अलग प्रतिमान का पालन करता है। व्यू में सब कुछ जावास्क्रिप्ट में रखने के बजाय, आपको केवल उस पर JS "छिड़कना" चाहिए।

किसी भी मामले में, एक ही स्थान पर HTML, CSS, JS, और रूबी से निपटना गड़बड़ हो सकता है। रेल्स व्यू बनाने में मुश्किल यह है कि डोमेन तर्क कभी-कभी व्यू के अंदर पाया जा सकता है। यह एक नो-नो है क्योंकि यह MVC पैटर्न को तोड़ता है, शुरुआत के लिए।

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

कंट्रोलर समस्याएं

रेल्स कंट्रोलर भी विभिन्न प्रकार की समस्याओं से पीड़ित हो सकते हैं। उनमें से एक फैट कंट्रोलर एंटी-पैटर्न है।

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

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

निष्कर्ष

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

अगली बार तक, चीयर्स!

P.S. यदि आप रूबी मैजिक पोस्ट को प्रेस से निकलते ही पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूज़लेटर की सदस्यता लें और कभी भी एक भी पोस्ट मिस न करें!