सादे कार्य-आधारित विचारों और इसके विपरीत की तुलना में ListView के पक्ष और विपक्ष क्या हैं? (Django)

मुझे लगता है कि यह समस्या दो अलग-अलग प्रोग्रामिंग शैली/आरेख, कार्यात्मक और OOP को संदर्भित करती है।

सामान्य OOP विचार के रूप में, Django में क्लास-आधारित दृश्य का उपयोग करने का सबसे अच्छा हिस्सा यह है कि आप अन्य वर्गों से इनहेरिट (और बहु-विरासत) प्राप्त कर सकते हैं, जो आपके विचार को और अधिक व्यापक बनाता है, और कोड पर पुन: प्रयोज्य।

उदाहरण के लिए, आपके पास views की एक श्रृंखला है जिसके लिए मुख्य प्रक्रिया ब्लॉक से पहले कुछ डेटा अखंडता जांच की आवश्यकता होती है, एक class-based view शैली में आप उन डेटा जांच कोड को एक अनुकूलित mixin में लिख सकते हैं जिसका उपयोग किया जाता है बहु-विरासत।

# mixins.py
# inherit from login required mixin and add data integrity check
class PostDataCheckMixin(LoginRequiredMixin):
    def dispatch(self, request, *args, **kwargs):
        try:
            data = json.loads(request.body.decode())
        except:
            return JsonResponse({'res': 0, 'errmsg': 'Invalid data'})
        return super().dispatch(request, *args, **kwargs)

# views.py
class OrderProcessView(PostDataCheckMixin, View):
    def post(self, request, *args, **kwargs):
    # ...

class OrderPaymentView(PostDataCheckMixin, View):
    def post(self, request, *args, **kwargs):
    # ...

यहां एक और उदाहरण विशेष रूप से ListView का उल्लेख करना चाहूंगा। जैसा कि आप जानते हैं कि बिल्ट-इन ListView डिफ़ॉल्ट रूप से pagination प्रदान करता है, आप कुछ इस तरह देख सकते हैं:

class ProductListView(ListView):
    model = ProductSKU
    context_object_name = 'products'
    template_name = 'shop/product-list.html'
    paginate_by = 3
    paginate_orphans = 1

और फिर जादुई रूप से आपके एचटीएमएल टेम्पलेट में, आपको कुछ संदर्भ चर जैसे page_obj, paginator और is_paginated मिलते हैं, उदाहरण के लिए:

          <!-- PAGINATION-->
          {% if is_paginated %}
          <nav aria-label="Page navigation">
            <ul class="pagination justify-content-center justify-content-lg-end">
              {% if page_obj.has_previous %}
              <!--...-->
              
              {% endif %}

              {% for num in paginator.page_range %}
              <li class="page-item {% if page_obj.number == num %} active {% endif %}">
                <a class="page-link" href="{% qs_url 'page' num request.GET.urlencode %}">{{ num }}</a>
              </li>
              {% endfor %}

              {% if page_obj.has_next %}
              <!--...-->
             
              {% endif %}
            </ul>
          </nav>
          {% endif %}

क्या चल रहा है? यदि आप स्रोत कोड की जांच करते हैं तो आप पाएंगे कि वे एक get_context_data पद्धति के अंदर हैं, जो उन context variables को आपके टेम्पलेट में पास करने के लिए तैयार करेंगे। इसके अलावा, आप आसानी से विस्तार कर सकते हैं कि आप अपने टेम्पलेट में विरासत में क्या पारित करना चाहते हैं, उदाहरण के लिए:

class ProductListView(ListView):
# ...
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs) 
        # at this moment your 'context' variable already contains 'page_obj', 'paginator' etc.

        category_slug = self.kwargs.get('category_slug')
        if category_slug:
            category = category_slug.replace('-', ' ')
            context['category'] = category 
            # here you add a new context variable 'category' 
        return context

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

वर्ग-आधारित विचारों का कठिन हिस्सा बहुत सार है, यह शुरुआत में खुद सहित कई लोगों को परेशान करता है, आपको पता नहीं है कि कोड इतना छोटा क्यों है और पर्दे के पीछे क्या हो रहा है।

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

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

विपक्ष स्पष्ट हैं, आप उन अंतर्निहित वर्ग-आधारित विचारों का पुन: उपयोग नहीं कर सकते हैं, जिनमें कई अच्छे कार्य और विशेषताएं हैं। वे एक विशाल समारोह में सब कुछ लिखने पर आपका समय कम कर देंगे।

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