मैं user
ऑब्जेक्ट का उदाहरण लेने जा रहा हूं। उपयोगकर्ता को पंजीकृत, लॉग इन, लॉग आउट, संपादित (उदाहरण के लिए, ईमेल परिवर्तन), आदिवेब एमवीसी: मॉडल परत को कैसे व्यवस्थित करें?
तो एक तरफ मेरे पास user
ऑब्जेक्ट है, जिसमें विभिन्न प्रकार के वर्ग चर (छद्म, ईमेल इत्यादि) शामिल हैं।) गेटर्स और सेटर्स के साथ और शायद कुछ ऐसे कार्य जो डीबी से निपटते नहीं हैं।
दूसरी ओर मेरे पास DAO
कक्षा है जो ऑब्जेक्ट है जो विभिन्न प्रकार के MySQL/PDO क्वेरीज़ (रिकॉर्ड, अद्यतन, जानकारी पुनर्प्राप्त आदि) के माध्यम से सीधे डेटाबेस से संबंधित है।
क्या user
ऑब्जेक्ट DAO
ऑब्जेक्ट के साथ सीधे बातचीत करने का कोई कारण नहीं है? दूसरे शब्दों में, जब Controller
किसी मौजूदा user
उदाहरण (उदाहरण के लिए, पंजीकरण प्रक्रिया के दौरान) से संबंधित डेटाबेस क्वेरी का अनुरोध करता है, तो इसे user
में केवल एक फ़ंक्शन कॉल करना चाहिए, जो स्वयं DAO
में कोई फ़ंक्शन कॉल करता है, या बीच में एक परत होनी चाहिए ?
मैंने ऐसे उदाहरण देखे हैं जहां नियंत्रक डीएओ के साथ बातचीत करने के लिए तीसरी कक्षा को कॉल करता है, और user
उदाहरण को एक तर्क के रूप में पास करता है। कभी-कभी इसके बजाय, यह तीसरी परत user
उदाहरण बनाने और DAO
से निपटने के साथ प्रभारी है। ऐसा लगता है कि DAO
से निपटने के लिए उपयोग किए जाने वाले सभी कार्यों user
ऑब्जेक्ट के अंदर रह सकते हैं। मैं क्या खो रहा हूँ?
-1: उस कोड में से कोई भी नियंत्रक में नहीं है। प्रस्तुति परत में आपके पास डोमेन व्यवसाय तर्क है। और आप 'उपयोगकर्ता' "कक्षा" कोई encapsulation या व्यवहार प्रदान करता है। –
ओह .. और 'userDAO' का आपका कोड उदाहरण वास्तव में डेटा मैपर है, [डीएओ नहीं] (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html)। डीएओ सीधे भंडारण के साथ बातचीत नहीं करते –
@ tereško अपने समाधान को उत्तर के रूप में पोस्ट करने के लिए स्वतंत्र महसूस करें। साथ ही, यह सुनिश्चित न करें कि आप कैसे कह सकते हैं कि मेरे पास प्रस्तुति परत में डोमेन व्यवसाय तर्क है जब मैंने प्रस्तुति परत का एक उदाहरण भी पोस्ट नहीं किया है। –