2009-11-02 16 views
7

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

प्रश्न: क्या यह एक मॉडल (नीचे/ऐप/मॉडल) या एक lib (under/lib) है।

मुझे इस पर कुछ धर्म चाहिए।

थ्योरी ए: (मेरा वर्तमान सिद्धांत) जब तक आप एक्शनमेलर :: बेस या एक्टिव रिकार्ड :: बेस इत्यादि को उप-वर्गीकृत नहीं कर रहे हैं, तो आपका कोड lib में जाना चाहिए।

थ्योरी बी: ​​(सिद्धांत जो मैं झुका रहा हूं) अनुप्रयोग-विशिष्ट हैं जो मॉडल में होना चाहिए। जो भी सामान्य उपयोग हो सकता है वह lib में होना चाहिए।

सिद्धांत सी: केवल "डेटा मॉडल" 'मॉडल' में होना चाहिए। एक्शनमेलर सबक्लास इस नियम को तोड़ते हैं, यद्यपि।

जहां तक ​​मुझे पता है, किसी भी तरह से यह ठीक काम करेगा, लेकिन मैं एक बनाम दूसरे के लिए किसी सूक्ष्म कार्यात्मक या दार्शनिक कारणों की तलाश में हूं।

विचार?

+0

मैं आपसे सहमत हूं: यदि यह ActiveRecord और सह से प्राप्त नहीं होता है, तो यह मॉडल नहीं होना चाहिए। मैंने उस विचार को पूर्ण उत्तर विचार में बदलने के लिए कहा नहीं है ^^ – marcgg

उत्तर

5

चाहे सक्रिय ActiveCecord या ActionMailer से संदेश प्राप्त हों या नहीं, तो संभवतः आप किसी भी ऑब्जेक्ट के लिए मॉडल चाहते हैं जो आपके विचार और नियंत्रक के साथ सहभागिता करते हैं। आपके मामले में, वे संदेश वर्ग के उदाहरणों को संभालेंगे - आप इसके लिए एक मॉडल चाहते हैं।

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

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

+0

क्या आपको लगता है कि यह थ्योरी बी से ऊपर है? –

+0

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

2

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

+0

क्या आपको लगता है कि यह थैरी बी से ऊपर है? –

1

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

संबंधित मुद्दे