क्या सॉर्टिंग लॉजिक को मॉडल, व्यू या कंट्रोलर में रखा जाना चाहिए? [बन्द है]

157

बंद हो गया । यह प्रश्न राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

6 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

मेरे पास एक ड्रॉप डाउन सूची है जो एक तालिका से अंत उपयोगकर्ता तक मूल्यों को प्रदर्शित करती है। मैं इन मूल्यों को वर्णानुक्रम से क्रमबद्ध करना चाहूंगा।

उचित MVC डिजाइन के अनुसार, मुझे किस स्तर पर अपना छंटनी तर्क देना चाहिए: मॉडल, दृश्य, या नियंत्रक?

EDIT : LarsH के प्रश्न के उत्तर में, "क्या आपका मतलब कोड है जो यह निर्धारित करता है कि किस प्रकार का ऑर्डर वांछित है? या कोड जो सॉर्ट करता है?", मैं मूल रूप से उस कोड का उल्लेख कर रहा था जो यह निर्धारित करता है कि किस प्रकार का ऑर्डर वांछित है।

asp.net-mvc model-view-controller

— रयान कोहन
स्रोत

6

टिप्पणियों में असहमति को हल करने के लिए, यह मददगार होगा यदि आप कहते हैं कि "सॉर्टिंग लॉजिक" से आपका क्या मतलब है। क्या आपका मतलब कोड है जो निर्धारित करता है कि किस प्रकार का ऑर्डर वांछित है? या कोड जो क्रमबद्ध करता है?

— लार्स

9

MVC डिजाइन कुछ विशेष या जादू नहीं है - यह वास्तव में सिर्फ एक प्रारंभिक बिंदु है। इसे अपनी आवश्यकताओं के अनुकूल बनाएं और याद रखें कि आप किसी भी समय रिफ्लेक्टर कर सकते हैं। मैंने देखा है कि विभिन्न विक्रेता अपने टूलकिट की जरूरतों के आधार पर नियंत्रक या दृश्य को फिर से परिभाषित करेंगे ताकि किसी भी समझौते को ढूंढना मुश्किल हो। महत्वपूर्ण बात यह है कि अपने मॉडल को अपने व्यू / कंट्रोलर से अलग करें। आपको MVP पैटर्न से अधिक माइलेज भी मिल सकता है, मेरा मानना है कि यह वास्तव में इस क्षेत्र में थोड़ा अधिक विशिष्ट है।

— बिल के

9

हो सकता है कि यह प्रोग्रामर को माइग्रेट कर दिया जाए।

— अल्फ्रेडो ओसोरियो

57

निश्चित रूप से नियंत्रक में। या तो वह या मॉडल। या दृश्य।

— भीड़

2

निश्चित रूप से कभी नहीं, कभी नहीं, कभी, कभी दृश्य में।

— '21

49

(नोट: यह उद्धरण और उद्धरण @ dasblinkenlight के उत्तर से लिया गया है , लेकिन हम इसकी व्याख्या पर असहमत हैं। उनकी पोस्ट पढ़ें और अपना स्वयं का मन बनाएं)।

एमवीसी विवरण के अनुसार ,

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

छँटाई तर्क (जैसे, छँटाई तुलनित्र / छँटाई एल्गोरिथ्म) मॉडल में है क्योंकि यह व्यापार नियम और राज्य डेटा शामिल हैं। चूँकि मॉडल डेटा को सॉर्ट करने के तरीके में परिवर्तन किया जाता है, इसलिए "मॉडल के दृश्य की प्रस्तुति को बदलें" श्रेणी में गिर जाता है, तो कंट्रोलर मॉडल.changeSortedState () विधि को कॉल करके "सॉर्टिंग" करने के लिए ज़िम्मेदार होता है।

— KyleM
स्रोत

8

क्या होगा यदि एक ही डेटा को दो अलग-अलग विचारों में प्रदर्शित किया जाए, अलग-अलग तरह से छांटा जाए?

— s4y

यह भी उसी तरह से किया जाना चाहिए, model.SortAscending () और model.SortDescending () और नियंत्रक द्वारा कहा जाता है।

— ब्रज

1

@ ब्रज उचित एमवीसी में, क्या दो विचार समान मॉडल साझा नहीं कर सकते हैं?

— KOVIKO

@Sidnicious यदि यह समझ में आता है कि एक छँटाई विधि है जो एक अलग पैरामीटर लेती है। उदाहरण के लिए public void Sort(bool sortByDescending = false), जहां झूठ बोलना आरोही द्वारा हल होता है। या बस दो अलग-अलग छंटनी विधियाँ हैं यदि तर्क बहुत अलग है।

— मैटमैक्गोवन

@Sidnicious के पास दो अलग-अलग मॉडल हैं जो सबकुछ सौंपते हैं लेकिन एकल तीसरे मॉडल के लिए सॉर्टिंग लॉजिक। docs.google.com/drawings/d/…

— 14

62

सॉर्ट क्रम को कौन नियंत्रित करता है?

सरल एमवीसी आरेख ( डॉ। से )

1) डेटा के भीतर ही प्राकृतिक क्रम:

आदेश मॉडल का हिस्सा है, इसलिए इसे वहां जाना चाहिए। "सभी डेटा" का एक कच्चा पुल डेटा को क्रमबद्ध क्रम में वापस कर देगा, और क्रम क्रम चुनने के लिए कोई इंटरफ़ेस नहीं है।

2) उपयोगकर्ता को नियंत्रित करना चाहिए कि वे डेटा कैसे देखते हैं:

दृश्य नियंत्रक के साथ सहभागिता करने वाला एक इंटरफ़ेस (जैसे आरोही / अवरोही तीर) प्रदान करेगा, और मॉडल डेटा को डेटा पर अनुरोधित सॉर्ट करने के लिए अच्छी तरह से समझता है। हालाँकि, डेटा के एक कच्चे पुल को जरूरी नहीं कि (1) के विपरीत क्रमबद्ध किया जाना चाहिए।

किसी भी स्थिति में,

देखें समझ में नहीं आता है कि एक प्रकार चल रहा है, अन्य कि किस प्रकार की दिशा दिखाने की क्षमता का चयन किया गया है। वहां तर्क मत रखो।

छोटा गुहा

छँटाई कार्यक्षमता विशुद्ध रूप से दृश्य में जा सकती है , एक परिस्थिति में (कि मैं अपमान के बारे में सोच सकता हूं; और भी हो सकता है)

एक "गूंगा" सॉर्ट जहां सभी डेटा पहले से ही दृश्य में है और इसे सॉर्ट करने के लिए किसी भी डोमेन ज्ञान का उपयोग करने की आवश्यकता नहीं है। उदाहरण के लिए बहुत ही साधारण स्ट्रिंग या संख्या की तुलना। यह संभव नहीं है, उदाहरण के लिए, एक वेबपेज पर खोज परिणाम जब परिणाम कई पृष्ठों में विभाजित होने की संभावना है।

— Izkata
स्रोत

58

दृश्य उपयोगकर्ता देख सकता है !?

— Farzher

41

मॉडल दृश्य को अद्यतन करता है !?

— deceze

13

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

— काइलएम

4

@cHao ज़रूर हम इस बात से सहमत हो सकते हैं कि विकिपीडिया का ग्राफ हालांकि अजीब है, है ना? :)

— छल

6

@StephenSarcsamKamenar और अन्य सभी: नहीं, छवि सही अर्थ बनाती है: यह डेटा का प्रवाह दिखा रहा है , कोड कनेक्शन नहीं।

— इज़काता

18

एमवीसी विवरण के अनुसार ,

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

इसके अनुसार, नियंत्रक में सॉर्टिंग लॉजिक होता है, क्योंकि मॉडल डेटा को सॉर्ट करने के तरीके में फेरबदल करने से "मॉडल की व्यू प्रजेंटेशन बदलें" श्रेणी में वर्गाकार रूप से गिरता है।

संपादित करें: टिप्पणियों में दी गई कई गलतफहमियों को स्पष्ट करने के लिए, "सॉर्टिंग लॉजिक" वह कोड नहीं है जो सॉर्ट करता है; यह कोड है जो सॉर्ट को परिभाषित करता है। सॉर्टिंग लॉजिक एक ऑर्डर (उदाहरण के माध्यम से IComparator<T>) स्थापित करने के लिए एक दूसरे से अलग-अलग वस्तुओं की तुलना करता है या इसमें लॉजिक होता है जो किसी बाहरी सिस्टम द्वारा ऑर्डर करने के लिए उपयोग की जाने वाली ऑब्जेक्ट का निर्माण करता है (उदाहरण के माध्यम से IOrderedQueryable<T>)। यह तर्क आपके नियंत्रक में है, क्योंकि इसे आपके आवेदन के "व्यवसाय" पक्ष से संबंधित ज्ञान की आवश्यकता है। यह सॉर्ट करने के लिए पूरी तरह से पर्याप्त है, लेकिन यह उस कोड से अलग है जो वास्तव में प्रदर्शन करता हैयह। कोड जो आपके प्रकार का हो सकता है, आपके मॉडल में, या यहां तक कि दृढ़ता परत में भी हो सकता है जो आपके मॉडल का समर्थन करता है (उदाहरण के लिए आपके कंप्यूटर डेटाबेस)।

— डायस्ब्लिंकनेलाइट का पता चलता है
स्रोत

12

-1 आपने इस उद्धरण से कैसे निष्कर्ष निकाला? क्या वहाँ कहीं कहा गया था कि नियंत्रक को मॉडल से जानकारी प्राप्त करना चाहिए? नियंत्रक राज्य को बदलने के लिए आदेश भेजता है। जानकारी निकालने या हेरफेर करने के बारे में कुछ नहीं कहा गया है।

— tereško

3

@ tereško आपने मेरे जवाब से निष्कर्ष निकालने का प्रबंधन कैसे किया कि नियंत्रक को मॉडल से जानकारी प्राप्त करने की आवश्यकता है? "सॉर्टिंग लॉजिक" से मेरा मतलब केवल एक लॉजिक है जो ऑर्डर करने के लिए आवश्यक है - सी # शर्तों में, जो कि एक कार्यान्वयन प्रदान कर रहा है IComparer<T>। मॉडल से डेटा की पुनर्प्राप्ति सहित छँटाई के शेष "बॉयलरप्लेट मैकेनिक्स" दृश्य पर निर्भर है।

— dasblinkenlight

3

".. सॉर्टिंग लॉजिक कंट्रोलर में होता है .." , इसका और क्या मतलब है?

— tereško 13

3

"एक नियंत्रक अपने संबंधित दृश्य को दृश्य की प्रस्तुति को बदलने के लिए कमांड भेज सकता है" वास्तव में ऐसा लगता है कि दृश्य नियंत्रक से आदेश के जवाब में छंटाई करेगा।

— सैमुअल एडविन वार्ड

1

@ केलीएम लेकिन दृश्य में हमेशा पर्याप्त ज्ञान नहीं होता है जिसमें छांटने वाले तर्क होते हैं। उदाहरण के लिए, एक ऐसे क्षेत्र पर विचार करें, जिसमें एक समरूप कोड है जो किसी एक Enums का है {Unknown, Pass, Fail}। आगे यह मानकर Unknownचलना चाहिए कि उपयोगकर्ता द्वारा उठाए गए अवरोही या अवरोही क्रम की परवाह किए बिना हमेशा अंतिम क्रमबद्ध होना चाहिए। दृश्य में इस तर्क को रखने से codeक्षेत्र के अंदर डेटा की व्यावसायिक प्रकृति के बारे में आपका दृष्टिकोण बहुत अधिक हो जाएगा । दृश्य को यह नहीं पता होना चाहिए: यह सभी जानते हैं कि उपयोगकर्ता ने एक "सॉर्ट" इशारा किया (उदाहरण के लिए हेडर पर क्लिक किया); बाकी नियंत्रक पर निर्भर है।

— dasblinkenlight

10

इनमे से कोई भी नहीं। छंटनी व्यापार तर्क है, और व्यापार तर्क तीनों में से किसी में नहीं है। आपके एप्लिकेशन का प्रत्येक टुकड़ा मॉडल, दृश्य या नियंत्रक नहीं होगा।

मैं अपने एमवीसी ऐप्स में आम तौर पर क्या करता हूं क्या मेरे पास एक सेवा परत है जो सभी व्यावसायिक तर्क करता है। सर्विस लेयर की विधियों में एक साफ सुथरा एपीआई होना चाहिए जिसमें अच्छी तरह से नामित पैरामीटर हों। फिर आप मॉडल में डेटा में हेरफेर करने के लिए अपने नियंत्रक से उन तरीकों को लागू कर सकते हैं।

उस अर्थ में, सॉर्टिंग "नियंत्रक" में है, लेकिन कोड जो स्वयं सॉर्टिंग करता है, उसे नियंत्रक में लागू नहीं किया जाना चाहिए, केवल वहां से आह्वान किया गया है।

— nont
स्रोत

5

मुझे हाल ही में सूचित किया गया है कि कुछ लोग "सर्विस लेयर" (व्यावसायिक तर्क) को मॉडल का हिस्सा मानते हैं।

— मार्वो

@ मेरवो मुझे लगता है कि कुछ ऐसे मामले हैं जहाँ तर्क के कुछ टुकड़े इतनी तीव्रता से उनके डेटा प्रकार से बंधे होते हैं कि उन्हें एक कक्षा में एक साथ एनकैप्सुलेट करना समझ में आता है। (उदाहरण के लिए समय और दिनांक कार्य)। सामान्य तौर पर, हालांकि, मुझे लगता है कि यह सबसे अच्छा काम करता है जब मॉडल ऑब्जेक्ट डेटा के अलावा कुछ भी नहीं करते हैं।

— 15

फिर व्यावसायिक तर्क एमवीसी पैटर्न में "लाइव" कहां है?

— मैरियो

2

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

— nont

एक मॉडल के विन्यास फाइल भाग को आसानी से समझ सकता है। मॉडल के लिए डेटाबेस होना जरूरी नहीं है। मैं यह नहीं कह रहा कि आप सही हैं या गलत। मैं सिर्फ आपको सुझाव दे रहा हूं कि जैसा कि मैंने हाल ही में किया है (क्योंकि मैंने आपके पास वही दृश्य रखा है) विषय को थोड़ा ऊपर उठाएं और देखें कि दूसरे क्या कह रहे हैं।

— मार्वो

8

निश्चित रूप से नियंत्रक नहीं: यह देखने और मॉडल के लिए संदेश भेजता है लेकिन जितना संभव हो उतना कम काम करना चाहिए। यदि उपयोगकर्ता उस सॉर्टिंग को बदल सकता है जो नियंत्रक को मॉडल या इसके बारे में दृश्य बताकर नियंत्रित करता है।

हो सकता है कि देखें कि यह शुद्ध दृश्य है या नहीं। यदि अनुप्रयोग बिना छँटाई के भी काम करता है तो छँटाई केवल प्रतिनिधित्व का हिस्सा है और इसे देखने में जाना चाहिए।

यदि आदेश डोमेन का अंतर्निहित हिस्सा है तो इसे मॉडल में जाना चाहिए।

— जेन्स स्काउडर
स्रोत

क्या "एक तुलनित्र या एक प्रकार का विवरणक प्रदान करना" को "काम करने" के रूप में गिना जाता है? क्योंकि एक छँटाई तर्क तुलनित्र या सॉर्ट डिस्क्रिप्टर में समझाया गया है, भले ही "सॉर्टिंग कार्य" सॉर्ट विधि या मॉडल के बैक-एंड में किया गया हो।

— dasblinkenlight

निर्भर करता है कि आप क्या प्रदान करते हैं: ठीक है। लेकिन तुलनाकर्ता मॉडल या दृश्य का हिस्सा होना चाहिए, न कि नियंत्रक का।

— जेन्स स्काउडर

6

दृश्य MVC का हिस्सा हैं, जिसमें प्रस्तुति तर्क को शामिल किया जाता है।
मॉडल परत वह जगह है जहां व्यावसायिक तर्क निहित है।
उपयोगकर्ता इनपुट के आधार पर नियंत्रक केवल दोनों की स्थिति को बदलते हैं।

तो पसंद यह है - क्या आपको लगता है कि यह डोमेन व्यवसाय तर्क या प्रस्तुति तर्क का हिस्सा है।

यदि आप एक उचित MVC Model2 या शास्त्रीय MVC पैटर्न को लागू कर रहे थे, तो मैं कहूंगा कि मॉडल लेयर द्वारा प्रदान किए गए डेटा के ऑर्डर को मॉडल लेयर के दृश्य के अनुरोध से ट्रिगर किया जाना चाहिए। देखें ऑर्डर किए गए डेटा के लिए पूछें, मॉडल परत प्रदान करता है।

लेकिन, जब से आप ASP.NET MVC की MVC पैटर्न की व्याख्या का उपयोग कर रहे हैं, जो थोड़ा अलग है तो आपका मानक MVC - ViewModel उदाहरण को मॉडल परत से जानकारी का आदेश देने का अनुरोध करना चाहिए (किसी कारण से ASP.NET फ्रेमवर्क सोचता है कि टेम्पलेट्स को बुलाया जाना चाहिए। "विचार" और विचारों को "दृश्यमॉडल" कहा जाना चाहिए .. यह अजीब है)।

— tereško
स्रोत

12

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

— dasblinkenlight

1

@dasblinkenlight, हाँ, मैं कई विषयों को डाउनवोट करता हूं क्योंकि वे सभी निहित हैं कि नियंत्रक को छंटाई करनी चाहिए। क्या गलत है। और .. लोग .. कृपया मेरी टिप्पणियों को केवल इसलिए रोक देना क्योंकि आप असहमत हैं।

— tereško

बस स्पष्ट होने के लिए: मैंने आपके उत्तर को गलत नहीं ठहराया क्योंकि यह गलत नहीं है, और मैंने कभी भी आपकी किसी भी टिप्पणी को हरी झंडी नहीं दी, क्योंकि मैं तब किसी भी तरह से अपमानजनक नहीं हूं। ईमानदारी से, मुझे नहीं पता कि आपका जवाब कैसे इतने सारे डाउनवोट पाने में कामयाब रहा: मुझे लगता है कि वे बीमार हैं।

— dasblinkenlight

@dasblinkenlight naah .. मैं अपनी टिप्पणियों के बारे में गुस्से में था जो इस विषय में गायब हो गए।

— tereško

5

मैं आमतौर पर इसे अन्य उत्तरों के अनुसार पैटर्न के अनुरूप रहने के लिए नियंत्रक में करूंगा। तर्क करने के लिए नीचे देखें।

मैं इसे खत्म कर रहा हूं और उत्तर और संबंधित सामग्री पढ़ रहा हूं और व्यावहारिक रूप से बोल रहा हूं कि मैं कहूंगा कि यह आपके आवेदन पर निर्भर करेगा उदाहरण के लिए:

क्या यह एक मध्यम / बड़ा अनुप्रयोग है और / या इसके साथ कई UI जुड़ा हुआ है (यानी एक विंडोज ऐप, वेब इंटरफ़ेस और फ़ोन इंटरफ़ेस)।

इस मामले में मैं शायद एक सेवा परत का निर्माण करूँगा और इसे व्यवसायिक वस्तु में डाल दूंगा और फिर नियंत्रक से उपयुक्त विधि कहूँगा।

यदि इसकी एक अच्छी तरह से परिभाषित एकल यूआई वेबसाइट है और आप ईएफ कोड फर्स्ट जैसी किसी चीज का उपयोग कर रहे हैं और आपके पास सर्विस लेयर बनाने का कोई इरादा नहीं है और न ही इसे एक्सेप्ट करने के लिए एक सरल आउट ऑफ बॉक्स एक्सटेंशन विधि का उपयोग करने की योजना है।

इस मामले में मैं शायद इसे नियंत्रक के रूप में व्यावहारिक रूप से समय / बजट के संबंध में सबसे अच्छा फिट मानूंगा।

यदि इसका उपरोक्त BUT बॉक्स एक्सटेंशन विधि के साथ लागू नहीं किया जा सकता है।

मैं अच्छी तरह से इसे मॉडल वर्ग में पॉप करने के लिए चुन सकता हूं (यदि इसकी एकल प्रकार से संक्षिप्त रूप से) तो यह एक नियंत्रक की तुलना में यहां अधिक उपयुक्त होगा। यदि सॉर्ट एक से अधिक वर्ग के लिए लागू किया जा सकता है, तो मैं इसे एक विस्तार विधि में लागू करूंगा और फिर इसे नियंत्रक में कॉल करूंगा।

सारांश में:

डॉगमैटिक उत्तर: सेवा परत

व्यावहारिक उत्तर: आमतौर पर नियंत्रक

— ल्यूक बूघन
स्रोत

"दृश्य के लिए डेटा तैयार करने" के लिए कौन सी परिभाषा नियंत्रक जिम्मेदार है?

— tereško

1

@ tereško: जहाँ मॉडल "निष्क्रिय" है, जैसा कि यहाँ खंडित खंड में msdn.microsoft.com/en-us/library/ff649643.aspx लिखा गया है। "HTTP इसका एक उदाहरण है" देखें। जबकि एक शुद्धतावादी यह विवाद कर सकता है कि एमवीसी में शुरू होने वाले शुरुआती लोगों के लिए यह आसान हो सकता है जहां वे ईएफ या अन्य मॉडल का उपयोग सीधे नियंत्रक में कर सकते हैं और बीएएल के माध्यम से नहीं, यह सोचने के लिए कि इस तरह से पैटर्न को समझने में बाधा को कम किया जा सकता है।

— ल्यूक बुगान

1

आप जिस बारे में बात कर रहे हैं वह "एनीमिक मॉडल" है।

— tereško

नोट किया गया है, जैसा कि आपने सुझाव दिया है, मैंने आपत्तिजनक विवरण हटा दिए हैं। इनपुट के लिए चीयर्स!

— ल्यूक बुगान

3

मैं एक तालिका-डेटा से डेटा सॉर्ट करने का सुझाव दूंगा जो ड्रॉपडाउन सूची में उपयोगी होने के लिए काफी छोटा है, जो डीबी से पहले से ही क्वेरी के माध्यम से सॉर्ट किया जाना चाहिए। मेरे लिए, वह मॉडल उस स्थान को बनाता है जिस तरह से लागू किया जाता है।

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

— B0nk3r
स्रोत

2

जब भी मैं इस विचार से सहमत होता हूं कि सॉर्टिंग बिजनेस लॉजिक है क्योंकि इसे तोड़ने से इसकी उत्पत्ति होती है तो आप कुछ इस तरह से समाप्त हो जाएंगे जैसे "ग्राहक चाहेंगे कि उत्पाद पृष्ठ तिथि के अनुसार छांटे गए चित्रों के साथ प्रदर्शित हो" तो यह स्पष्ट हो जाता है कि डेटा के लिए क्रमबद्ध क्रम आमतौर पर मनमाना नहीं है - भले ही कोई छँटाई न हो क्योंकि अभी भी चूक से एक व्यापार निर्णय है (एक खाली सूची अभी भी एक सूची है)।

लेकिन ... ये उत्तर ओआरएम प्रौद्योगिकी के विकास को ध्यान में नहीं रखते हैं, मैं केवल एंटिटी फ्रेमवर्क के संबंध में बात कर सकता हूं (आइए एक तर्क से बचें कि क्या यह सच है ORM, यह बात नहीं है) Microsoft से यह वही है जो मैं उपयोग करता हूं, लेकिन मुझे यकीन है कि अन्य ओआरएम समान कार्यक्षमता प्रदान करते हैं।

यदि मैं MS MVC और Entity फ्रेमवर्क का उपयोग करके उत्पाद वर्ग के लिए एक मजबूत टाइप का दृश्य बनाता हूं और उत्पाद और छवि तालिका (जैसे FK_Product_Image_ProductId) के बीच एक विदेशी कुंजी संबंध है, तो मैं जल्दी से आउट-ऑफ-बॉक्स सक्षम हो जाऊंगा उनके प्रदर्शन के दौरान चित्र कुछ इस तरह से देखने में:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

एक विशिष्ट व्यावसायिक तर्क परत का उल्लेख था, जिसका उपयोग मैं अपने व्यवसाय तर्क का 80% प्रदर्शन करने के लिए भी करता हूं, लेकिन मैं अपने व्यवसाय तर्क परत में उस प्रकार की कार्यक्षमता लिखने नहीं जा रहा हूं, जो किसी चीज की नकल करती हो इकाई ढांचे से।

मुझे नहीं लगता कि इस प्रश्न का कोई सही उत्तर है, ऐसा कहने के अलावा; आपको जटिल व्यावसायिक तर्क को सार करना चाहिए जहां संभव हो लेकिन पहिया को फिर से स्थापित करने की कीमत पर नहीं।

— लूटना
स्रोत

मैं एक ही बात सोच रहा था, यहाँ जवाब ORMs और एक्सटेंशन के तरीकों को ध्यान में नहीं लगते हैं। ज्यादातर मामलों में तर्क छांटना उतना ही सरल होगा myList.OrderBy(x => x.CreationDate)- वास्तव में ऐसा करने के लिए किसी भी अनावश्यक अतिरिक्त परत को लागू करने की आवश्यकता नहीं है। इसे जोड़ने के लिए, यदि उन्हें पृष्ठांकित और सॉर्ट किए गए डेटा की आवश्यकता है, तो वे क्या करेंगे? पूरी तालिका को छोड़ें, उसे क्रमबद्ध करें और फिर उन्हें क्या चाहिए? myList.OrderBy(x => x.Date).Skip((page-1)*pageSize).Take(pageSize)कोई बस कॉल कर सकता है और कोई अनावश्यक डेटा पुनर्प्राप्त नहीं किया जाता है।

— बाल्ज़

1

मान लें कि आपके पास MVC वेबसाइट, WebForms वेबसाइट और एक मोबाइल एप्लिकेशन है।

अगर आप इन प्रेजेंटेशन लेयर के बीच सुसंगत होना चाहते हैं, तो मैं कहूंगा कि प्रेजेंटेशन लेयर के बाहर सॉर्ट करें। सेवा एक अच्छा उम्मीदवार होगा।

अन्यथा, मैं उस तर्क को एक दृश्य मॉडल में संग्रहीत करूंगा। क्यों? क्योंकि यह पुन: प्रयोज्य और आसानी से परीक्षण योग्य होगा।

0

आपके द्वारा सूचीबद्ध तीन में से, मैं कहूंगा कि यह नियंत्रक में है। मैं वास्तव में नियंत्रक में इस तरह के तर्क रखना पसंद नहीं करता, हालांकि। मैं आमतौर पर एक सेवा परत बनाता हूं जो नियंत्रक के साथ संचार करता है जो डेटा स्टोर के साथ संचार करने और सॉर्टिंग लॉजिक को संभालने के लिए जिम्मेदार होगा। छोटे अनुप्रयोगों के लिए, यह ठीक नियंत्रक में बैठा है।

— Dismissile
स्रोत

2

यह तर्क को मॉडल पक्ष पर अधिक डाल देगा, सही?

— रयान कोहन

हाँ, "सर्विस लेयर" के बारे में मेरी समझ यह है कि यह मॉडल का हिस्सा है।

— मार्वो

0

यह asp.net को ध्यान में रखते हुए पूछा गया सवाल है, लेकिन चूंकि किसी ने रेल्स का उल्लेख किया है, इसलिए मुझे लगा कि इस संदर्भ में समस्या पर विचार करना दिलचस्प होगा। रेल में, फ्रेमवर्क और ActiveRecord / ActiveQuery एपीआई प्रावधानों के बाद से नियंत्रक कार्रवाई के रूप में पुनर्प्राप्ति के साथ-साथ छँटाई करना स्वाभाविक और सुंदर है। दूसरी ओर, स्थिर वस्तुओं के लिए कुछ प्रकार के कस्टम क्रम को परिभाषित करना संभव है और इसे नियंत्रक द्वारा उपयोग किए जाने वाले मॉडल में डाल दिया जाता है, इसलिए मॉडल छंटनी वाले तर्क में एक भूमिका निभा सकता है, भले ही वह बाहर न ले जाए सीधे ऑपरेशन। जो कुछ भी है, यह कहना सुरक्षित हो सकता है कि दृश्य में सॉर्ट लॉजिक को आमतौर पर रखा जाता है।

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

— prusswan
स्रोत