मैं एक एमवीसी ढांचे को डिजाइन करता हूं लेकिन मुझे नहीं पता कि मुझे अपनी उपयोगिता कक्षा कहां रखनी चाहिए। मैंने कहीं कहीं पढ़ा जहां कहा कि उपयोगिता वर्ग मॉडल वर्ग हैं। क्या यह सोचने की रेखा सही है या क्या वे कुछ अलग प्रकार की कक्षा हैं?क्या एक यूटिलिटी क्लास एमवीसी फ्रेमवर्क में मॉडल क्लास हो सकती है?
यह इस यूटिलिटी क्लासेस क्या कर रहा है इस पर निर्भर करता है। एमवीसी का मुख्य विचार शेष अनुप्रयोग (एम) से प्रस्तुति परत (वी और सी) को अलग करना है। यदि आपकी उपयोगिता कक्षाएं प्रेजेंटेशनल परत से संबंधित चीजों को संभालती हैं, तो उन्हें एक उचित पैकेज में रखें, उदाहरण के लिए व्यूहेल्पर या इनपुट हैंडलर। यदि उपयोगिता फ़ंक्शंस किसी और चीज से संबंधित है, तो देखें कि आपके मॉडल में कौन सी परत सबसे अच्छी फिट है, उदाहरण के लिए डेटाएप यूटिलिटीज डीएओ पैकेज में जाती है जबकि मेलहेल्पर सर्विस पैकेज में जा सकता है, और इसी तरह।
यदि यह संग्रहीत डेटा का प्रतिनिधित्व नहीं है, तो शायद यह मॉडल श्रेणी नहीं है। फिर भी, यदि यह अभी भी किसी प्रकार के संग्रहीत डेटा का प्रतिनिधित्व करता है, लेकिन आपके शेष मॉडल से मूल रूप से अलग व्यवहार करता है, तो यह अन्य मॉडलों से संबंधित नहीं हो सकता है, वैसे भी।
उपयोगिता फ़ंक्शंस मॉडल, व्यू या कंट्रोलर के लिए जो भी क्लास उपयोगिता है, उसका हिस्सा हो सकती है। यदि वे थोड़ी अधिक सामान्य हैं, तो वे एमवीसी डिज़ाइन के बाहर "बाहर" रहते हैं।
मॉडल सिर्फ डेटाबेस नहीं है! – Gordon
आप जानते हैं, जब मैंने पहली बार एसओ पर शुरुआत की, तो मुझे एमवीसी में मॉडल परत के बारे में बहुत सारे तर्क और भ्रम का सामना करना पड़ा। थोड़ी देर के बाद, मुझे यह अहसास हुआ कि एमवीसी करने के लिए बहुत सारे गलत तरीके थे। यह एक छोटा कोडबेस था जो एमवीसी को कम से कम तीन अलग-अलग तरीकों से खराब तरीके से बनाए रखने के बाद थोड़ा सा था। हालांकि, एक चीज जो सबसे सुसंगत थी वह यह थी कि मॉडल ** संग्रहित डेटा ऑब्जेक्ट्स मॉडलिंग **। इसका मतलब यह नहीं था कि यह सिर्फ एक ओआरएम परत था, लेकिन उन्हें पता होना चाहिए कि वे दूसरे के साथ कैसे बातचीत करते हैं और कैसे अपना डेटा स्टोर और पुनर्प्राप्त करते हैं। – staticsan
मॉडल श्रेणी में आपका डेटा एक्सेस कोड, एप्लिकेशन तर्क शामिल हो सकता है। इसलिए मॉडल में रखना ठीक है।
सबसे अच्छा तरीका मॉडल फ़ोल्डर में फ़ोल्डर उपयोगिता और जगह उपयोगिता वर्ग बनाने के लिए सबसे अच्छा तरीका है।
मैंने एक पुस्तक पढ़ी जहां उसने कहा कि मॉडल एक व्यापार परत और/या उपयोगिताओं से कक्षाएं हैं। व्यूहेल्पर होने का विचार नियंत्रकों और दृश्यों का संकर बनाना पसंद करता है। तुम क्या सोचते हो? – rix501
@ rix501 एक नियंत्रक UI से उपयोगकर्ता इनपुट को संभालता है और मॉडल को प्रतिनिधि अनुरोध करता है। ए [व्यूहेल्पर] (http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html) उपयोगकर्ता इनपुट को संभाल नहीं लेना चाहिए। मुख्य विचार अपने दृश्य टेम्पलेट से दूर प्रतिपादन को पूरा करने के लिए दृश्य द्वारा आवश्यक किसी भी तर्क को अलग करना है। पुस्तक में पढ़ा गया भेद सही है। यूटिलिटीज शब्द हालांकि अस्पष्ट है। – Gordon