आपको रेल ऐप में रीस्टफुल कंट्रोलर का उपयोग कब करना चाहिए, और आपको कब नहीं चाहिए?

Question

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

या शायद यह मेरी निपुण समझ है। मैं अब तीन साल से रेल कर रहा हूं, लेकिन आरईएसटी और फॉर्म हेल्पर्स एक साथ मुझे रहस्यमय लगते हैं।

Answer 1

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

मॉडल

class Position 
    has_many :candidate_positions 
    has_many :candidates, :through => :candidate_positions 
end 

class Candidate 
    has_many :candidate_positions 
    has_many :positions, :through => :candidate_positions 
    has_many :past_employments 
    accepts_nested_attributes_for :past_employments 
    accepts_nested_attributes_for :candidate_positions 
end 

class PastEmployment 
    belongs_to :candidate 
end 

class CandidatePosition 
    belongs_to :candidate 
    belongs_to :position 
end 

मार्गों

map.resources :positions 
map.resources :candidates 

उपयोगकर्ता कि मॉडल अवधि के साथ बातचीत के लिए एक गैर साधन संपन्न नियंत्रक का प्रयोग करें। उदाहरण के लिए, यदि आप HomeController चाहते हैं जो उपलब्ध पदों के साथ-साथ हालिया उम्मीदवारों को दिखाता है, तो यह एक नया, सादा नियंत्रक होगा। अगर आप इस नियंत्रक पर किसी भी जानकारी को संपादित करना चाहते हैं, तो शांत! आपके पास फॉर्म पोस्ट को संभालने के लिए पहले से ही नियंत्रक उपलब्ध हैं, जो स्वचालित रूप से <% form_for @candidate %> के साथ वायर्ड हो जाएंगे। आप <%= render @positions %> के साथ अपने पदों का संग्रह प्रस्तुत कर सकते हैं, और क्योंकि आपने उन्हें संसाधन बना दिया है, इसलिए रेल आंशिक आंशिक के लिए views/positions/_position.html.erb देखेंगे।

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

Answer 2

मुझे RoR नहीं पता है, इसलिए मैं आरईएसटी पर जेनरेट स्टेटमेंट करूंगा।

आरईएसटी और आरओआई यूआरएल को संज्ञाओं की श्रृंखला के रूप में मानता है, और यह क्रियाओं के रूप में जीईटी, पोस्ट, पुट, और डिलीट जैसे HTTP विधियों का उपयोग करता है। यह मॉडल सीआरयूडी के लिए काम करता है, और यहां तक ​​कि कई संघों के मॉडल के लिए भी काम करता है। चूंकि यूआरएल संसाधनों का प्रतिनिधित्व करता है, इसलिए संबंधित वस्तुओं को यूआरएल की सूची के रूप में व्यक्त किया जा सकता है।

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

Answer 3

अस्वीकरण: मुझे रेल पता है, लेकिन मैं अभी भी काफी नौसिखिया हूं। संक्षिप्त उत्तर: आरईएसटी और फॉर्म हेल्पर्स पूरी तरह से अलग-अलग क्षेत्र हैं।

लंबा उत्तर: जैसा कि मैं इसे समझता हूं, प्रतिनिधि राज्य स्थानांतरण केवल रूपों और विचारों के वास्तविक प्रतिपादन से ही कम है।

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

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

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

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

तो, आपका मुख्य प्रश्न क्या है? क्या आपके पास रेल फॉर्म हेल्पर्स के बारे में कोई विशिष्ट सवाल है? रेल नियंत्रकों के बारे में? या आरईएसटी के लिए विशिष्ट कुछ?

Answer 4

आप Railscasts की इस श्रृंखला है, जो बाकी के संदर्भ में के बारे में है-कई रिश्ते और रूपों में बात करती है की जाँच हो सकता है:

• Complex Forms Part 1
• Complex Forms Part 2
• Complex Forms Part 3