MVC में, DAO को नियंत्रक या मॉडल से बुलाया जाना चाहिए


14

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

यदि हम नियंत्रक में DAO आह्वान लिखते हैं, तो REST सेवा के लिए कार्यक्षमता का पुन: उपयोग करना संभव नहीं होगा? मैंने नीचे दोनों दृष्टिकोणों को संक्षेप में प्रस्तुत किया है।

दृष्टिकोण # १

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);

    }


 }

दृष्टिकोण # 2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

नोट -

यहाँ मॉडल की एक परिभाषा क्या है:

मॉडल: मॉडल एप्लिकेशन डोमेन के व्यवहार और डेटा का प्रबंधन करता है, अपने राज्य (आमतौर पर दृश्य से) के बारे में जानकारी के लिए अनुरोधों का जवाब देता है, और राज्य को बदलने के निर्देशों का जवाब देता है (आमतौर पर नियंत्रक से)।

ईवेंट-चालित प्रणालियों में, मॉडल पर्यवेक्षकों (आमतौर पर विचारों) को सूचित करता है जब जानकारी बदलती है ताकि वे प्रतिक्रिया कर सकें।

मुझे इस पर एक विशेषज्ञ की राय की आवश्यकता होगी क्योंकि मुझे # 1 या # 2 का उपयोग करने वाले कई मिलते हैं, इसलिए यह कौन सा है?


1
नियंत्रक को मॉडल से सब कुछ लोड करना चाहिए और इसे दृश्य में पास करना चाहिए।
jgauffin

क्या आपको सुझाव # 2 है?

1
"एक नियंत्रक मॉडल के दृश्य की प्रस्तुति को बदलने के लिए अपने संबद्ध दृश्य को कमांड भेज सकता है (उदाहरण के लिए, दस्तावेज़ के माध्यम से स्क्रॉल करके)। यह मॉडल की स्थिति को अपडेट करने के लिए मॉडल को आदेश भेज सकता है (उदाहरण के लिए, दस्तावेज़ संपादित करना)।" .. ईएमएम .. यह कहाँ कहता है, उस नियंत्रक को डेटा निकालना चाहिए या इसे पास करना चाहिए?
मेफिस्टो

जवाबों:


31

मेरी राय में, आपको एमवीसी पैटर्न और 3-स्तरीय वास्तुकला के बीच अंतर करना होगा। सारांश में:

3-स्तरीय वास्तुकला:

  • डेटा: लगातार डेटा;
  • सेवा: आवेदन का तार्किक हिस्सा;
  • प्रस्तुति: hmi, webservice ...

MVC पैटर्न उपरोक्त आर्किटेक्चर (एक वेबएप के लिए) की प्रस्तुति स्तरीय में होता है:

  • डेटा: ...;
  • सेवा: ...;
  • प्रस्तुतीकरण:
    • नियंत्रक: HTTP अनुरोध को स्वीकार करता है और HTTP प्रतिक्रिया देता है;
    • मॉडल: स्टोर किए गए डेटा को प्रदर्शित / इलाज करने के लिए;
    • दृश्य: आउटपुट / प्रदर्शन को व्यवस्थित करता है।

एक सामान्य HTTP अनुरोध का जीवन चक्र :

  1. उपयोगकर्ता HTTP अनुरोध भेजता है;
  2. नियंत्रक इसे स्वीकार करता है;
  3. नियंत्रक उपयुक्त सेवा को कॉल करता है;
  4. सेवा उपयुक्त डाओ को बुलाती है, जो कुछ स्थायी डेटा (उदाहरण के लिए) लौटाता है;
  5. सेवा डेटा का इलाज करती है, और नियंत्रक को डेटा लौटाती है;
  6. नियंत्रक डेटा को उपयुक्त मॉडल में संग्रहीत करता है और उपयुक्त दृश्य को कॉल करता है;
  7. दृश्य मॉडल के डेटा के साथ त्वरित हो जाता है, और HTTP प्रतिक्रिया के रूप में वापस मिलता है।

1
जिसे आप "विशिष्ट HTTP अनुरोध का जीवन चक्र" कहते हैं , वह MVC नहीं है। और DAO सिर्फ एक ऑब्जेक्ट है, जो डोमेन लॉजिक और दृढ़ता के बीच बातचीत / अनुवाद की सुविधा देता है। यह सक्रिय रिकॉर्ड के लिए एक अलग नाम नहीं है। इसके अलावा .. जब से मॉडल प्रस्तुति का हिस्सा बन गया है ?!
मेफिस्टो

1
@teresko 1) हां, यह MVC है, लेकिन 3-स्तरीय वास्तुकला के भीतर। यदि नहीं, तो क्यों? 2) आप सही थे, मैंने संपादित किया। 3) चूंकि पूरा एमवीसी पैटर्न प्रेजेंटेशन टियर में होता है। विशिष्ट उदाहरण: स्प्रिंग एमवीसी, जिनके मॉडल केवल मुख्य-मूल्य वाले जोड़े वाले मैप हैं। स्प्रिंगफ्यूज़ ने इसे भी चुना है।
sp00m

2
मुझे यहां @ sp00m से सहमत होना होगा ... एक सामान्य HTTP अनुरोध का उनका वर्णन MVC वेब ऐप के लिए सटीक है, और प्रस्तुति के भाग के रूप में मॉडल (MVC में 'M' के रूप में) की स्थिति भी सही है । N-tier MVC ऐप्स में, 'मॉडल' आमतौर पर नीचे दिए गए बाकी स्तरों पर प्रस्तुति स्तरीय का मुखौटा है।
एरिक किंग

8

मॉडल लेयर से।

अधिक सटीक होने के लिए: सेवाओं से, जो मॉडल परत में निहित हैं , क्योंकि वे डोमेन ऑब्जेक्ट्स और स्टोरेज लॉजिक एब्स्ट्रक्शन के बीच बातचीत को नियंत्रित करते हैं।

मॉडल परत की स्थिति को बदलने के लिए नियंत्रक केवल जिम्मेदार होना चाहिए। DAO दृढ़ता तंत्र का हिस्सा हैं। यह डोमेन व्यवसाय और एप्लिकेशन लॉजिक का एक हिस्सा है। यदि आप नियंत्रक में DAO के साथ बातचीत करना शुरू करते हैं, तो आप प्रस्तुति परत में डोमेन तर्क को लीक कर देंगे ।


एक सेवा परत का उपयोग करने के लिए, यह DDD पैटर्न होना चाहिए? यदि मैं गलत हूं तो मुझे सही करों। क्या हमारे पास MVC में सर्विस लेयर है?

आप ले सकते हैं। डोमेन लॉजिक को एप्लिकेशन लॉजिक से अलग करने के लिए सेवाओं का उपयोग किया जाता है। यह आवश्यक हो जाता है, फिर आप शुद्ध CRUD डोमेन संरचनाओं (सक्रिय रिकॉर्ड) से स्थानांतरित होते हैं, कुछ ऐसा है जो डोमेन लॉजिक से स्टोरेज लॉजिक को अलग करता है। पूरी तरह से महसूस किए गए मॉडल परत में आपके पास 3 तार्किक अलगाव हैं: दृढ़ता, डोमेन और एप्लिकेशन।
मेफिस्टो

3

मुझे यकीन नहीं है कि आधिकारिक एमवीसी पैटर्न क्या कहता है, लेकिन मैं आमतौर पर नियंत्रकों और डीएओ के बीच एक "सेवा" परत रखना पसंद करता हूं। नियंत्रक अनुरोध से डेटा खींचता है और इसे उपयुक्त सेवा वर्ग में भेजता है। सेवा वर्ग एक या अधिक डीएओ को कॉल करने के लिए जिम्मेदार है जो मॉडल क्लास (एस) को पास करते हैं। उन मॉडल कक्षाओं को फिर कंट्रोलर को वापस भेजा जाता है ताकि दृश्य परत पर भेजा जा सके। सेवा परत को पुन: उपयोग में मदद करता है क्योंकि कई नियंत्रक एक ही सेवा परत विधियों का उपयोग कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.