रूबी ऑन रेल्स पैटर्न और एंटी-पैटर्न का परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सॉन्ग मॉडल SongFinders . का विस्तार करेगा मॉड्यूल, इसलिए इसकी विधियाँ वर्ग विधियों के रूप में उपलब्ध हैं। गाने के मॉडल में SongConverter . शामिल होगा मॉड्यूल, इसलिए इसके तरीके मॉडल इंस्टेंस पर उपलब्ध हैं।

यह सब हमारे गाने के मॉडल को बहुत पतला और बिंदु पर बनाना चाहिए:

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 और Ruby से निपटने में गड़बड़ी हो सकती है। रेल विचारों के निर्माण के साथ क्या मुश्किल है कि डोमेन तर्क कभी-कभी दृश्य के अंदर पाया जा सकता है। यह एक नो-नो है क्योंकि यह शुरुआत के लिए एमवीसी पैटर्न को तोड़ता है।

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

नियंत्रक समस्याएं

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

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

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

निष्कर्ष

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

अगले एक तक, चीयर्स!

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