वर्तमान पृष्ठांकन कार्यान्वयन के डिजाइन पर प्रश्न


12

मैंने विशेष रूप से asp.net mvc पर पृष्ठांकन कार्यान्वयन की जाँच की है और मुझे वास्तव में लगता है कि कार्यान्वयन में कुछ कम कुशल है।

सबसे पहले सभी कार्यान्वयन नीचे की तरह पृष्ठांकन मूल्यों का उपयोग करते हैं।

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

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

दूसरी बात यह है कि वे नीचे इंटरफेस का उपयोग करते हैं।

public interface IPagedList<T> : IList<T>
{
    int PageCount { get; }
    int TotalItemCount { get; }
    int PageIndex { get; }
    int PageNumber { get; }
    int PageSize { get; }
    bool HasPreviousPage { get; }
    bool HasNextPage { get; }
    bool IsFirstPage { get; }
    bool IsLastPage { get; }
} 

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

एक और बात यह है कि वे नीचे कोड को देखने में उपयोग करते हैं

Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)

यदि मॉडल IPagedList है, तो वे एक अधिभार पद्धति की तरह क्यों नहीं प्रदान करते हैं जैसे @Html.Pager(Model)कि बेहतर भी है @Html.Pager()। आप जानते हैं कि हम मॉडल प्रकार इस तरह से जानते हैं। इससे पहले कि मैं गलती कर रहा था क्योंकि मैं Model.PageNumber के बजाय Model.PageIndex का उपयोग कर रहा था।

एक और बड़ा मुद्दा यह है कि वे IQueryable इंटरफ़ेस पर दृढ़ता से निर्भर हैं। वे कैसे जानते हैं कि मैं अपने डेटा स्तर में IQueryable का उपयोग करता हूं? मुझे उम्मीद है कि वे केवल संग्रह के साथ काम करेंगे जो कि पेजिनेशन कार्यान्वयन दृढ़ता बनी हुई है।

उनके पृष्ठांकन कार्यान्वयन पर मेरे सुधार विचारों के बारे में क्या गलत है? इस तरह से उनके पेजिंग्स को लागू न करने का क्या कारण है?


यह मुझे काफी जटिल लगता है। ऐसा नहीं है कि मैंने काफी समझा है कि वास्तव में समस्या क्या है, लेकिन ... क्या आपको वास्तव में अंतर्निहित सहायकों का उपयोग करने की आवश्यकता है? मुझे पता भी नहीं था कि उनके पास पेजर है। मैंने अपने स्वयं के सहायकों का एक संग्रह विकसित किया है क्योंकि MVC 1 बीटा के दिनों के बाद से मेरे पहले (और असफल) में निर्मित सहायकों के साथ प्रयास करने का प्रयास किया गया है। मैं आपको यही सलाह देता हूं। यदि आप उन सहायकों के साथ संघर्ष कर रहे हैं तो यह WebForms से बेहतर नहीं है जहाँ आप सर्वर नियंत्रण से जूझ रहे थे।

ASP.NET MVC ने पेजिनेशन हेल्पर्स में कोई बिल्ट नहीं किया है, सिर्फ थर्ड पार्टी पेजिनेशन इम्प्लीमेंटेशन हैं।
फ्रेशबल्ड

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

मैं सिर्फ यह जानना चाहता था कि क्या मेरे विचारों में कुछ गड़बड़ है। क्या मैंने कुछ मूल सिद्धांतों को तोड़ा है यदि ऐसा नहीं है तो उन सभी ने अपने कार्यान्वयन पर समान डिजाइन का पालन किया है .. मुझे यह नहीं मिला
Freshblood

यदि कोई कोड प्रोग्रामर प्रोग्रामर की समस्या को हल नहीं करता है, तो कोड का कोई मूल्य नहीं है, आप बेहतर तरीके से इसका उपयोग करने से बचते हैं।
शहीर

जवाबों:


1

जैसा कि user8685 ने कहा: आपका इंटरफ़ेस मौजूदा MVC सामान और सिद्धांतों के लिए बेमानी लगता है।

इसे आज़माएं: IPagedList से आपके लिए आवश्यक जानकारी, जैसे पेज इंडेक्स आदि को बिजनेस लॉजिक लेयर में लागू किया जाना चाहिए और एक जेनेरिक मॉडल के माध्यम से व्यू / पेज पर फीड किया जाना चाहिए जिसे सर्वर पर वापस फीड किया जा सकता है और सुरक्षित रूप से वहां डाला और प्रोसेस किया जा सकता है। क्यों? क्योंकि आप यहां जो कुछ भी स्पष्ट रूप से एकत्र कर रहे हैं, वह आपकी सूचना प्रणाली के लिए एक इनपुट है और जैसा कि यूआई से कम परतों का है।

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

इसके अलावा, मौजूदा सहायकों में अक्सर सरल उपयोग के लिए बहुत अधिक ओवरहेड होते हैं और कभी-कभी बड़ी तस्वीर को बाधित करते हैं।


0

इस IPagedList या सहायक चीज़ का उपयोग नहीं किया है, लेकिन यह मेरा लेना है:

MostPopular(int pageIndex,int pageSize)एक स्पष्ट इंटरफेस बताते हुए है: मैं केवल वापस आ जाएगी पृष्ठों MostPopular चीजों की। आप स्पष्ट रूप से मुझे बताएं कि कौन सा पृष्ठ और उसका आकार है।

यदि उन्होंने एक नियंत्रक विधि बनाई थी MostPopular(IPagedList<T> page), तो इंटरफ़ेस अधिक भ्रामक हो जाता है। क्या आप नियंत्रक को वस्तुओं की कुल मात्रा बता रहे हैं या नहीं?

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

इसका मतलब यह नहीं है कि IPagedList है मॉडल, यह सिर्फ रूप में अच्छी तरह से हो सकता है के भाग के एक मॉडल (उस पर एक संपत्ति)। यह संभावना है कि क्यों कोई पैरामीटर-कम अधिभार नहीं है।

वे एक ओवरलोड के रूप में IPagedList को जोड़ सकते थे, लेकिन फिर आप एक सेट (डेटा का एक पृष्ठांकित हिस्सा) एक छोटे से पेजर सहायक को पारित करेंगे जो वास्तविक डेटा की आवश्यकता नहीं है। बस यह जानने की जरूरत है कि इस समय आपके कितने पेज / आइटम हैं और आप कहां हैं इसलिए यह पेज नंबर और इस तरह हाइलाइट कर सकता है। आप सहायक को कहीं अधिक बताएंगे फिर उसे काम करने के लिए जानना होगा। जिस तरह से यह अब काम करता है उसमें कम कपलिंग है, जो अच्छी बात है।


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

0

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

public ActionResult MostPopulars(int pageIndex,int pageSize)

यह करने का एक सुंदर समझदार तरीका है। मैंने उन विविधताओं को देखा है, जहां (पहले, अगले, प्रचलित, अंतिम) का एक प्रयोग किया गया था, लेकिन वास्तव में "पेजइंडेक्स" कहने का सिर्फ एक अजीब तरीका है।

मैं उस पृष्ठ का आकार फिर से दोहराऊंगा और इसमें बहुत कुछ अलग होना चाहिए, इसमें शामिल दर्शक के आधार पर आपको मोबाइल, पोर्टेबल्स और बिग स्क्रीन वर्कस्टेशन के लिए अलग-अलग डिफॉल्ट मिलने चाहिए, साथ ही, कई मामलों में अंतिम उपयोगकर्ता को यह चुनने के लिए समझदार होना चाहिए कि आपके आइटम का गठन कैसे होता है एक पन्ना।

मुझे पता है कि यह एक एमवीसी ढांचे के भीतर गुजरने वाले बहुत सारे मापदंडों का परिणाम है, लेकिन पेजिंग की पूरी अवधारणा एमवीसी को तोड़ देती है - आपके व्यवसाय तर्क को पेजिंग के लिए प्रस्तुति के बारे में जानना आवश्यक है ताकि काम हमेशा गड़बड़ हो जाए।

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