ऐसे व्यवसाय तर्क कहां रखा जाए? सेवा बनाम डीएओ?

Question

दिया गया:

1. वसंत एमवीसी - हाइबरनेट।
2. नियंत्रक -> सेवा -> डीएओ
3. अब मैं एक तरीका है जिसके डीबी से कुछ और everytime यह ऐसा करता है प्राप्त करता है, किसी अन्य विधि कहते हैं कि "processList" (बस सूची में कुछ मूल्यों में परिवर्तन के आधार की तरह कुछ करने के लिए है है कुछ स्क्रीन पैरामीटर पर)।

प्रश्न:

1. क्या परत मैं इस "processList" रख सकता हूं? (नियंत्रक, सेवा या डीएओ? और क्यों)

मैं वास्तव में, अब कुछ J2EE स्पष्टीकरण की जरूरत मुझे पता है कि MVC सभी भाषाओं में एक ही है, लेकिन मैं सिर्फ यह सुनिश्चित करने की आवश्यकता है :) अगर मैं .net में यह कर रहा हूं निस्संदेह यह सेवा में डाल दिया होगा।

Answer 1

यह वास्तव में processList पर निर्भर करता है कि वास्तव में क्या कर रहा है। कोई सुनहरा नियम नहीं है। मेरे द्वारा अनुसरण किए जाने वाले कुछ नियम हैं:

1. कभी भी उसी परत पर मुख्य वस्तुओं के बीच कॉल न करें।
   • ManagementServiceImpl को कभी भी NotificationServiceImpl पर कॉल नहीं करना चाहिए।
2. वस्तुओं के बीच परिपत्र निर्भरता न बनाएं।
   • यह उपर्युक्त के समान है।
3. आप अपने आप को लगता है यदि एक से अधिक मुख्य उद्देश्य भर में कुछ तर्क दोहरा, कोड पुनर्गठन और विशेष तार्किक वर्गों में यह निकालने के लिए कोशिश (इस इकाई परीक्षण के रूप में अच्छी तरह से सुधार होगा)।
   • उदा। UserUpdateHandler या NotificationDispatcher (ये अभी भी सेवा परत के स्वामित्व में हैं -> कोई भी किसी और उन्हें फोन करने के लिए अनुमति दी है) ... जहां यह तार्किक अंतर्गत आता है
4. कोड रखो।
   • इस तथ्य से विचलित न हों, कि कुछ वर्ग को कुछ करने की आवश्यकता है। यह कोड के लिए सही जगह नहीं हो सकता है।
5. आपको आवश्यकता से पहले पूरी तरह से सामान्यीकृत कोड कभी नहीं लिखें।
   • यह समय से पहले सामान्यीकरण, जो समय से पहले अनुकूलन के समान एक बुरी बात है के रूप में अपनी अवधि है। कोड की कुछ पंक्तियों को सहेजने से भविष्य में आपके बालों को खींचने का कारण बन सकता है।
6. हमेशा सामान्य कोड बनने में सक्षम कोड लिखें।
   • यह पिछले के साथ एक विरोधाभास नहीं है। यह कहता है - हमेशा सामान्यीकरण के साथ दिमाग में लिखें, हालांकि इसकी आवश्यकता नहीं होने पर लिखित से परेशान न हों। आगे सोचो, लेकिन जरूरी नहीं कि आगे कार्य करें।
7. सेवा परत पर डेटा तर्क छोड़ें, डेटा परत पर डेटा दृढ़ता तर्क और प्रेजेंटेशन परत पर उपयोगकर्ता इंटरैक्शन तर्क।
   • सेवा परत में उपयोगकर्ता इनपुट को पार्स करने का प्रयास न करें। यह वही नहीं है जैसा कि ई-शॉप एप्लिकेशन में अंतिम मूल्य की गणना करना प्रस्तुति परत से संबंधित नहीं है।

---

processList के लिए कुछ उदाहरण:

• उदाहरण मैं - के माध्यम से Hibernate#initialize
  • अतिरिक्त संबंधों को लाते समय यह कुछ है जो सेवा और डीएओ परत के बीच में वास्तव में है । पुरानी परियोजनाओं पर हमने FetchHandler वर्ग (सेवा परत के स्वामित्व वाले) विशेषीकृत किया था। नई परियोजनाओं में हम इसे पूरी तरह से डीएओ को छोड़ देते हैं।
• उदाहरण II - सूची के माध्यम से जाने के लिए और परिणाम के लिए व्यापार सत्यापन संदेश जोड़ने
  • सेवा परत, कोई संदेह नहीं
• उदाहरण तृतीय - सूची के माध्यम से जाने के लिए और तैयार सत्यापन त्रुटियों के आधार पर यूआई संदेश
  • प्रस्तुति परत

---

साइड नोट:

• MVC त्रि-स्तरीय वास्तुकला से एक अलग बात है।
• एम मॉडल सभी तीन परतों में फैलता है। प्रस्तुति परत में वी विचार और सी नियंत्रक दोनों शामिल हैं।