आपके सत्यापन मुद्दे के संबंध में, यह इस बात पर निर्भर करता है कि आप क्या मान्य कर रहे हैं।
यदि डेटा आपके समस्या डोमेन से ऑब्जेक्ट बनाता है, जिसे मॉडलों के रूप में भी जाना जाता है, तो आपको ActiveModel से निर्मित सत्यापनकर्ताओं का उपयोग करना चाहिए। यह शायद आपको क्या करना चाहिए, लेकिन सटीक समस्या को जानने के बिना कहना मुश्किल है। Rails Guides on Validations देखें। आप बता सकते हैं कि क्या यह खुद से पूछकर मामला है कि सत्यापन के लिए आवश्यक डेटा को संग्रहीत करने के बाद संग्रहीत किया जाएगा। यदि हां, तो यह निश्चित रूप से एक मॉडल है। इस प्रकार के डेटा का एक उदाहरण ब्राउज़र ब्लॉग से ब्लॉग पर भेजे जाने वाले ब्लॉग पोस्ट का शीर्षक और टेक्स्ट फ़ील्ड होगा।
यदि डेटा आपके मॉडल के लिए कुछ तृतीयक है, या प्रेजेंटेशन के लिए विशिष्ट है, तो आपको मददगारों का उपयोग करके ठीक होना चाहिए। आपने देखा कि मददगार ज्यादातर विचारों में उपयोग किए जाते हैं, और हालांकि यह सच है, आपको नियंत्रकों में उनका उपयोग करने से रोकने के लिए कुछ भी नहीं है, आपको केवल यह घोषणा करना होगा कि आप ActiveController#helper विधि का उपयोग करके उनका उपयोग करेंगे। ApplicationController कक्षा के अंदर, बहुत से देव सभी 0 नियंत्रकों में सभी सहायकों को शामिल करने के लिए डाल देंगे। एक बार कोड की आवश्यकता हो जाने के बाद, यह वास्तव में उस प्रदर्शन को बड़ा नहीं करता है।
ध्यान दें कि लगभग सभी आने वाले डेटा को मॉडल का उपयोग करके मॉडलिंग किया जा सकता है। रेल दुनिया में विचार का एक बड़ा स्कूल फैट मॉडल विचार की सदस्यता लेता है। लोग कहते हैं कि मॉडल में जितना संभव हो उतना कोड डालना और जितना संभव हो सके नियंत्रक में कम से कम चिंताओं को अलग करता है और अधिक रखरखाव कोड की ओर जाता है। इससे पता चलता है कि भले ही आपको नहीं लगता कि आने वाला डेटा मॉडल योग्य है (इस अर्थ में कि आप इसका प्रतिनिधित्व करने के लिए एक मॉडल बना सकते हैं), आपको इसे एक मॉडल बनाने और इसे सत्यापित करने के आसपास तर्क को समाहित करने का प्रयास करना चाहिए। हालांकि, आप पाते हैं कि एक सहायक कार्य करना तेज है, और या तो काम करेगा।
उपयोगकर्ता इनपुट को सत्यापित करने की आपकी धारणा एक अच्छी है। मुझे यह महसूस हो रहा है कि जब आप रेल के लिए नए हैं तो आप इन चीजों को स्वयं करने के लिए उपयोग करते हैं, लेकिन यह यहां काफी लागू नहीं होता है। रेल की दुनिया में, फ्रेमवर्क द्वारा सत्यापन की तरह कई सामान्य सामानों को संभाला जाता है।आपको params सरणी में उपस्थिति की जांच करने की आवश्यकता नहीं है, इसके बजाय आप मॉडल पर validates_presence_of पर कॉल करें और रेल को उपयोगकर्ता को त्रुटि थूकने दें। यह लंबे समय तक चीजों को आसान बनाता है अगर आप फ्रेमवर्क को जो भी डिजाइन करते हैं, उसे करने दें।
lib फ़ोल्डर के बारे में आपके प्रश्न के संबंध में, यह वास्तव में कोई फर्क नहीं पड़ता। आप रूट निर्देशिका में lib फ़ोल्डर में विविध समर्थन फ़ाइलों और पुस्तकालयों को रख सकते हैं और वे आपके एप्लिकेशन (app फ़ोल्डर में फ़ाइलों) के उपयोग के लिए उपलब्ध होंगे। आप अपने कोड को प्लगइन या मणि में भी अमूर्त करना चुन सकते हैं और इसे इस तरह शामिल कर सकते हैं, जिसमें बहुत से लोग ऐसा करने का विकल्प चुनते हैं। इसके लिए मेरा सुझाव डाइविंग से पहले रत्न और प्लगइन्स की धारणा पर पढ़ना होगा।
धन्यवाद hornais, बहुत उपयोगी स्पष्टीकरण! आप सही हैं कि फ्रेमवर्क को सामान्य सामान करने की बजाय मुझे इन चीजों में से बहुत कुछ करने के लिए उपयोग किया जाता है। यह समझ में आता है कि रेल आपके लिए यह करती है, मुझे बस इसका उपयोग करना होगा। मैं मॉडल स्तर पर इनपुट को प्रमाणित करने का प्रयास करूंगा। – Naatan