2012-03-15 11 views
7

मान लें कि प्रत्येक डोमेन इकाई के लिए, मेरे पास एक भंडार है जो डेटा मैपर को एपीआई प्रदान करता है। उदाहरण के लिए, यदि मेरे पास UserEntity है, तो मेरे पास एक UserRepository होगी जो डेटाबेस में उपयोगकर्ता डेटा को बनाए रखने के लिए UserMapper से बात करती है।नई डोमेन इकाइयां कहां बनाएं? नियंत्रक, भंडार, या मैपर?

अब, मान लीजिए कि एक वेब पेज पर एक फॉर्म सबमिट किया गया है, और मेरे नियंत्रक को पता है कि सबमिट की गई जानकारी के आधार पर इसे एक नई उपयोगकर्ता प्रविष्टि बनाने की आवश्यकता है।

यह करता है:

  1. मौके पर वहीं नई UserEntity (करते हैं), और सबमिट किए गए फ़ॉर्म के आंकड़ों के अनुसार सभी आवश्यक सेटर तरीकों चलाने के लिए, तो, रेपो को UserEntity पारित जो गुजरता सम्मिलन के लिए मैपर?

    नियंत्रक बनाता UserEntity => रेपो => मैपर => डीबी

  2. एक सरणी में प्रपत्र डेटा बारी

    , और यह UserRepository जो तब नई UserEntity() और setters चलाता है के पास है, और को पास कर सम्मिलन के लिए मैपर?

    नियंत्रक उपयोगकर्ता डेटा गुजरता => रेपो बनाता UserEntity => मैपर => डीबी

  3. UserRepository, जो नए UserEntity और प्रविष्टि के लिए नक्शाकार को सरणी से गुजरता है करने के लिए सरणी पारित?

    नियंत्रक उपयोगकर्ता डेटा गुजरता => रेपो गुजरता उपयोगकर्ता डेटा => मैपर बनाता UserEntity => डीबी

किसका जिम्मेदारी यह वस्तुओं के निर्माण का प्रबंधन करने के लिए है?

उत्तर

1

यह उत्तर देने का एक कठिन सवाल है। मेरे दो सेंट कुछ कारणों से नंबर 1 पर हैं। सबसे पहले, यह माना जाता है कि आपके पास अपनी इकाई में डोमेन सत्यापन है जो पारित होने वाले डेटा को बहुत अच्छी तरह से अस्वीकार कर सकता है। अगर वह 2 या 3 में होता है तो आप अस्वीकृति से पहले कुछ वस्तुओं को गहरा कर चुके हैं। 2/3 और 1 के बीच के अंतर के संदर्भ में यह बहुत मेमोरी या निष्पादन समय नहीं हो सकता है, लेकिन यह एक अंतर है। मैं तेजी से असफल होने की कोशिश करता हूं।

दूसरा, मुझे लगता है कि नियंत्रक को डेटा के साथ-साथ वस्तुओं को पारित करने के बारे में जानना पूरी तरह से स्वीकार्य है। मैं "वसा मॉडल, पतला नियंत्रक" से सहमत हूं लेकिन कह रहा हूं कि नियंत्रक इकाइयों के बारे में नहीं जान सकते हैं नियंत्रक भी मेरी पसंद के लिए पतला बना रहा है।

+0

यह स्थिति का एक बड़ा विश्लेषण है। मैं अन्य विचारों को सुनने के लिए उत्सुक हूं, लेकिन मुझे लगता है कि इसे नियंत्रक में बनाने के लिए स्वीकार्य है। हालांकि, शायद कम लचीलापन? उदाहरण के लिए, यदि मैं डीबी में उपयोगकर्ता तालिका में कोई नया फ़ील्ड जोड़ता हूं, तो मुझे प्रत्येक नियंत्रक पर जाना याद रखना होगा जो उपयोगकर्ताEntities बनाता है। – johnnietheblack

+0

आप संभवतः उस दृश्य को संपादित कर रहे हैं जो नई जानकारी (मान लीजिए कि हम पारंपरिक वेब एप्लिकेशन के बारे में बात कर रहे हैं) स्वीकार करते हैं, नियंत्रक को संपादित करना बहुत अधिक खिंचाव नहीं है। संभावना है कि अगर आप उस नियंत्रक को संपादित करना भूल गए हैं जिसे आप दृश्य को संपादित करना भूल गए हैं। इसके अलावा, एक साधारण वैश्विक खोज यह पता लगा सकती है कि आपकी कक्षा का उपयोग कहां किया जाता है। – Crashspeeder

+0

एक और अच्छा मुद्दा, और यदि नियंत्रक उत्तर है, तो मैं परेशान नहीं हूं ... लेकिन फिर भी, मेरे हिस्से का हिस्सा है जो कई स्थानों पर एक ही तत्काल प्रक्रिया को लिखने "दोषी" महसूस करता है। नहीं? इसी तरह, मेरे विचारों को स्थापित किया गया है ताकि फॉर्म फ़ील्ड जोड़ने के लिए जो नई तालिका परिवर्तन को प्रतिबिंबित करे, केवल एक फ़ाइल में बदलाव की आवश्यकता होगी। – johnnietheblack

2

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

नियंत्रकों

मैं आवेदन की गोंद के रूप में नियंत्रक पर विचार करें। हम उन सभी चिंताओं को अलग कर सकते हैं जिन्हें हम जितना संभव हो उतने टुकड़ों में चाहते हैं, लेकिन रेखा के साथ कहीं, कुछ दृश्य पक्ष और मॉडल पक्ष को समझना है, और वह वस्तु नियंत्रक है। ऐसा कहा जा रहा है, मेरा मानना ​​है कि नियंत्रकों को पतला होना चाहिए, इसलिए नियंत्रक का एकमात्र वास्तविक काम एक प्रतिक्रिया के लिए अनुरोध को मैप करना है। किसी भी तरह की इंटरमीडिएट प्रोसेसिंग कहीं और लात मार दी जानी चाहिए।

एक सीआरयूडी ऐप में, नई वस्तुओं को तत्काल करने और उन्हें नियंत्रक में रखने के लिए बहुत आसान है, यहां तक ​​कि यह एक से अधिक बार किया जाता है, क्योंकि यह पेस्ट करने के लिए केवल कुछ पंक्तियां हैं। क्या होगा यदि वस्तु निर्माण छोटा नहीं था? मैं कई जटिल रिश्तों के साथ एक आवेदन बनाए रख रहा हूं और उपयोगकर्ता द्वारा सबमिट किए गए निर्माण में अक्सर कई वस्तुओं के निर्माण की आवश्यकता होती है। नियंत्रक-और-मॉडल-केवल पर्यावरण में बनाए रखना संभव नहीं है। FormHandler और प्रबंधक:

अतिरिक्त सेवा परतें

इस संभाल करने के लिए, मैं 2 अतिरिक्त सेवा परतों बना लिया है। हर बार जब कोई फॉर्म सबमिट किया जाता है, तो फॉर्म सामग्री फॉर्म हैंडलर परत पर भेजी जाती है। फॉर्म हैंडलर आने वाले फॉर्म डेटा को समझने और सामान्य करने के लिए ज़िम्मेदार हैं। प्रपत्र हैंडलर डेटा को प्रसंस्करण के लिए उचित प्रबंधक ऑब्जेक्ट्स में पास कर सकते हैं। प्रबंधक ऑब्जेक्ट डेटा को संसाधित करते हैं और डोमेन परत को अद्यतन करते हैं। वे मॉडल बनाने, मॉडल बदलने, और बैकएंड में बने रहने के लिए जिम्मेदार हैं।

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

निष्कर्ष

इस डिजाइन के साथ:

Controller -> FormHandler -> ModelManager -> Mapper

मैंने पाया मेरी सभी वर्गों अब यूनिट परीक्षण योग्य अच्छी तरह से किया जा रहा है चिंताओं की जुदाई की वजह से (यहां तक ​​कि कुछ हद तक नियंत्रकों) कर रहे हैं विभाजित, और बातचीत का एक बिंदु डुप्लिकेट तर्क से बचने के लिए एक वरदान है।

नोट्स

मेरे मन में रेपो केवल डेटाबेस क्वेरी करने के लिए है -, यह पूछ अगर यह कुछ है नई चीजें बनाने नहीं।

इस मामले में मेरा अनुभव Symfony 2 और सिद्धांत का उपयोग करने से है 2.

YMMV; जैसे आप प्रपत्र परत अनावश्यक हो सकते हैं, लेकिन मुझे डोमेन मॉडल को समझने के लिए डेटा/रूप से डेटा परिवर्तन के लिए डेटा रूपांतरण के लिए बहुत आसान लगता है।

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