एमवीसी फ़ोल्डर संरचना में, सामान्य वर्ग फ़ाइलों को कहां रखा जाना चाहिए? उदाहरण के लिए, मेरे पास एक कक्षा है जो सही डेटा कॉन्टेक्स्ट का उपयोग करने के लिए निर्धारित करती है, इसलिए मैं अपने प्रत्येक नियंत्रक में पहिया को पुन: पेश नहीं कर रहा हूं। क्या यह नियंत्रक फ़ोल्डर में रहना चाहिए, भले ही यह नियंत्रक न हो? क्या यह मॉडल के साथ होना चाहिए क्योंकि यह डेटाबेस से संबंधित है, भले ही यह मॉडल न हो? संभवतः दृश्य \ साझा फ़ोल्डर? या सामग्री उस तरह के सामान के लिए कैच-ऑल फ़ोल्डर है? मुझे यकीन है कि मैं इसे कहीं भी रख सकता हूं, लेकिन मैं सोच रहा था कि "सही" जगह कहां है।एमवीसी सामान्य वर्ग स्थान
उत्तर
यह नियंत्रक, सामग्री या दृश्य नहीं है, इसलिए उन का उपयोग न करें। यह आपके मॉडल से सबसे करीबी से संबंधित लगता है, इसलिए आप इसे "हेल्पर्स" या "यूटिलिटी" या कुछ ऐसे नामक उपफोल्डर के तहत मॉडल में डाल सकते हैं। या आप सेवाओं नामक एक और शीर्ष स्तर फ़ोल्डर जोड़ सकते हैं और इसे वहां रख सकते हैं। यही वह जगह है जहां मैंने अपने सभी ऐप तर्क, नियंत्रक और मॉडल के बीच मध्य व्यक्ति डाल दिया।
यदि यह स्वयं से उपयोगी हो सकता है (इसके चारों ओर बनाए गए कमांड लाइन टूल के बारे में सोचें), इसे मॉडल फ़ोल्डर में रखें। यदि इसे केवल नियंत्रकों के लिए सहायक के रूप में उपयोग किया जाता है, तो इसे नियंत्रक फ़ोल्डर में रखें।
आप रोब के MVC स्टोरफ्रंट को देखें, तो: (Commerce.MVC.Data) की तरह अलग वर्ग पुस्तकालय परियोजना
यह रॉब के बारे में नहीं है, यह उससे भी अधिक है - यह जिम्मेदारियों को अलग करने और बस इस तरह के एक मानक दृष्टिकोण है। डेटा एक्सेस के पास एप्लिकेशन की प्रस्तुति परत में कोई व्यवसाय नहीं है जब तक कि हम एक-पेज एप्लिकेशन के बारे में बात नहीं कर रहे हों, जहां यह अधिक समझ में नहीं आता है। –
यह वास्तव में यह क्या करता है, अगर यह डेटा यह डेटा एक्सेस परत में होना चाहिए तक पहुँचता है पर निर्भर करता है, अन्यथा आप इसे नियंत्रक फ़ोल्डर में डाल सकते हैं।
dmajkic,
क्यों यह अलग अपनी ही क्षेत्र में? यदि इसका बीएलएल कोड यह नियंत्रक फ़ोल्डर में होना चाहिए, यदि इसकी डीएएल संबंधित वस्तु मॉडल में होनी चाहिए। मैं समझ सकता हूं कि कोई परियोजना बड़ी हो जाती है और आप कुछ सबफ़ोल्डर बनाना चाहते हैं, जो कोई मुद्दा नहीं होना चाहिए। लेकिन किसी अन्य स्तर में कोड डालने से वास्तव में एमवीसी के उद्देश्य को हराया जाता है, क्या आपको नहीं लगता?
सं। एमवीसी एक दृश्य पैटर्न है। यह प्रस्तुति परत से संबंधित है। नियंत्रकों में केवल प्रस्तुति तर्क होना चाहिए। नियंत्रक कक्षाओं में एक व्यापार तर्क नहीं होना चाहिए। दमजिक ने कक्षा को एक अलग परियोजना में रखने के लिए कहा, एक अलग स्तर नहीं। – liammclennan
@liammclennan - बिल्कुल, मुझे नहीं पता कि अल धूम्रपान क्या कर रहा है, लेकिन शायद उसे छोड़ना चाहिए। –
एक अलग डेटा एक्सेस असेंबली है, उस कक्षा को आंतरिक बनाएं और इसे DataContextFactory कहते हैं।
- 1. सामान्य एमवीसी
- 2. एमवीसी पैटर्न में मुख्य वर्ग की स्थान और जिम्मेदारियां
- 3. numpy.ndarray: एक "सामान्य" वर्ग
- 4. सीएसएस - सामान्य वर्ग
- 5. सशर्त सामान्य वर्ग
- 6. एक सामान्य वर्ग
- 7. एक सामान्य वर्ग
- 8. एक सामान्य वर्ग
- 9. एक सामान्य अमूर्त वर्ग
- 10. सामान्य functor वर्ग जावा
- 11. सामान्य रूपांतरण प्रकार वर्ग
- 12. रजिस्टर सामान्य पृष्ठ आधार वर्ग
- 13. जावाडोक जब गैर सामान्य वर्ग
- 14. अमूर्त वर्ग (सामान्य संबंध) के लिए विदेशीकी
- 15. सी # जेनेरिक्स - एक सामान्य वर्ग से सामान्य विधि कॉलिंग
- 16. हाइबरनेट: कैसे, सुपर वर्ग सामान्य इकाई मैप की सुपर वर्ग
- 17. एकता App.config फ़ाइल में एक सामान्य वर्ग
- 18. सामान्य वर्ग में जेनेरिक विधि नाम बनाना?
- 19. ASP.NET MVC सामान्य आधार दृश्य वर्ग
- 20. ग # - इसके आधार गैर सामान्य वर्ग
- 21. कैसे एक गैर सामान्य वर्ग निर्माता
- 22. सी # जेनरिक: वर्ग जहां विधि सामान्य
- 23. फैक्टरी वर्ग एक सामान्य इंटरफ़ेस लौटने
- 24. जावा: कैसे भीतरी यथा-स्थान वर्ग
- 25. पीएचपी नाम स्थान और शामिल करें() वर्ग
- 26. एएसपीनेट एमवीसी और सामान्य एचटीएमएल पेज
- 27. सामान्य एमवीसी से एजेक्स/जेएसओएन/आरईएसटी
- 28. एमवीसी 3 आरसी रेजर @helper स्थान
- 29. एमवीसी 3 - कस्टम विशेषता वर्ग कहां रखें
- 30. जावा में एक सामान्य वर्ग के लिए एक सामान्य कन्स्ट्रक्टर कैसे बनाया जाए?
आपने प्रेजेंटेशन लेयर प्रोजेक्ट में अपना सभी एप्लिकेशन लॉजिक लगाया है? भयानक लगता है .... –
छोटी परियोजनाओं के लिए मैंने इसे वहां रखा। अगर सेवाओं का पुन: उपयोग किया जाएगा, तो उन्हें अपनी परियोजना मिल जाएगी। –