Django एप्लिकेशन या मोटे मॉडल में कोड व्यवस्थित करने के बारे में ठीक है

मोटे मॉडल।

परिचय

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

Django में MVC = MTV + एम्बेडेड C

क्या आपने कभी यह समझाने की कोशिश की है कि एमटीवी django में कैसे काम करता है, उदाहरण के लिए, एक RoR डेवलपर के लिए? कोई सोच सकता है कि टेम्पलेट दृश्य हैं, और दृश्य नियंत्रक हैं। वास्तव में ऐसा नहीं है। एक नियंत्रक एक django अंतर्निहित URL राउटर है जो अनुरोध-प्रतिक्रिया तर्क प्रदान करता है। सही पैटर्न में सही डेटा का प्रतिनिधित्व करने के लिए दृश्यों की आवश्यकता होती है। टेम्प्लेट और प्रस्तुतियाँ मिलकर फ्रेमवर्क की एक "प्रस्तुति" परत का निर्माण करते हैं।

ऐसे एमटीवी के कई फायदे हैं - इसकी मदद से, आप आसानी से और जल्दी से ठेठ बना सकते हैं और न केवल एप्लिकेशन। हालाँकि, यह स्पष्ट नहीं है कि डेटा को संसाधित करने और संपादित करने के लिए तर्क कहाँ संग्रहीत किया जाना चाहिए, किन मामलों में कोड को सार करने के लिए। आइए कई अलग-अलग तरीकों का मूल्यांकन करें और उनके आवेदन के परिणामों को देखें।

दृश्य में तर्क

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

def accept_quote(request, quote_id, template_name="accept-quote.html"): quote = Quote.objects.get(id=quote_id) form = AcceptQuoteForm() if request.METHOD == 'POST': form = AcceptQuoteForm(request.POST) if form.is_valid(): quote.accepted = True quote.commission_paid = False #   provider_credit_card = CreditCard.objects.get(user=quote.provider) braintree_result = braintree.Transaction.sale({ 'customer_id': provider_credit_card.token, 'amount': quote.commission_amount, }) if braintree_result.is_success: quote.commission_paid = True transaction = Transaction(card=provider_credit_card, trans_id = result.transaction.id) transaction.save() quote.transaction = transaction elif result.transaction: #  ,      celery logger.error(result.message) else: #  ,      celery logger.error('; '.join(result.errors.deep_errors)) quote.save() return redirect('accept-quote-success-page') data = { 'quote': quote, 'form': form, } return render(request, template_name, data) 

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

रूपों में तर्क

Django में प्रपत्र ऑब्जेक्ट-ओरिएंटेड होते हैं, वे डेटा को मान्य और साफ़ करते हैं, यही वजह है कि उन्हें तर्क का स्थान भी माना जा सकता है।

 def accept_quote(request, quote_id, template_name="accept-quote.html"): quote = Quote.objects.get(id=quote_id) form = AcceptQuoteForm() if request.METHOD == 'POST': form = AcceptQuoteForm(request.POST) if form.is_valid(): #     form.accept_quote() success = form.charge_commission() return redirect('accept-quote-success-page') data = { 'quote': quote, 'form': form, } return render(request, template_name, data) 

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

कक्षा आधारित दृश्यों में कोड

दृष्टिकोण पिछले एक के समान है - समान लाभ, समान नुकसान। हमारे पास कंसोल या बाहरी अनुप्रयोगों से तर्क तक पहुंच नहीं है। इसके अलावा, परियोजना में देखने की योजना जटिल है।

utils.py

एक और सरल और लुभावना तरीका सबमिशन से सभी सब-कोड को अमूर्त करना और इसे एक अलग फ़ाइल में उपयोगिता कार्यों के रूप में रखना है। ऐसा लगता है कि सभी समस्याओं का एक त्वरित समाधान (जो कई अंततः चुनते हैं), लेकिन चलो थोड़ा सोचते हैं।

 def accept_quote(request, quote_id, template_name="accept-quote.html"): quote = Quote.objects.get(id=quote_id) form = AcceptQuoteForm() if request.METHOD == 'POST': form = AcceptQuoteForm(request.POST) if form.is_valid(): #    utility- accept_quote_and_charge(quote) return redirect('accept-quote-success-page') data = { 'quote': quote, 'form': form, } return render(request, template_name, data) 

पहली समस्या यह है कि ऐसे कार्यों का स्थान स्पष्ट नहीं हो सकता है, कुछ मॉडलों से संबंधित कोड कई पैकेजों में फैला हो सकता है। दूसरी समस्या यह है कि जब आपकी परियोजना बढ़ती है और नए / अन्य लोग उस पर काम करना शुरू करते हैं, तो यह स्पष्ट नहीं होगा कि कौन से कार्य मौजूद हैं। जो बदले में, विकास के समय को बढ़ाता है, डेवलपर्स को परेशान करता है और कोड दोहराव का कारण बन सकता है। एक कोड समीक्षा में कुछ चीजों को पकड़ा जा सकता है, लेकिन यह एक पोस्ट फैक्टम सॉल्यूशन है।

समाधान: वसा मॉडल और वसा प्रबंधक

मॉडल और उनके प्रबंधक डेटा को संसाधित करने और अद्यतन करने के उद्देश्य से कोड को इनकैप्सुलेट करने के लिए एक आदर्श स्थान है, खासकर जब ऐसा कोड तार्किक या कार्यात्मक रूप से ORM की क्षमताओं से बंधा हो। संक्षेप में, हम अपने तरीकों से एपीआई का विस्तार करते हैं।

 def accept_quote(request, quote_id, template_name="accept-quote.html"): quote = Quote.objects.get(id=quote_id) form = AcceptQuoteForm() if request.METHOD == 'POST': form = AcceptQuoteForm(request.POST) if form.is_valid(): #      quote.accept() return redirect('accept-quote-success-page') data = { 'quote': quote, 'form': form, } return render(request, template_name, data) 

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

सारांश: सामान्य एल्गोरिथ्म

कहाँ कोड @ ब्लर लिखना है ? यदि आपका तर्क अनुरोध ऑब्जेक्ट से बंधा है, तो यह संभवतः दृश्य में जगह है। अन्यथा, विकल्पों के निम्नलिखित क्रम पर विचार करें:

• मॉडल विधि में कोड
• प्रबंधक विधि में कोड
• कोड विधि विधि में
• सीबीवी विधि में कोड

यदि कोई भी विकल्प फिट नहीं है, तो यह एक अलग उपयोगिता फ़ंक्शन में अमूर्त करने पर विचार करने के लायक हो सकता है।

टीएल, डॉ

मॉडल में तर्क django अनुप्रयोगों में सुधार करता है, न कि आपके बालों का उल्लेख करने के लिए ।

बोनस

मूल विषय की टिप्पणियों में लेख के विषय के करीब दो दिलचस्प अनुप्रयोगों के लिंक फिसल गए।

github.com/kmmbvnr/django-fsm - django मॉडल (विवरण से) के लिए राज्य मशीन समर्थन । मॉडल पर FSMField फ़ील्ड सेट करें और रिसीवर की भावना में डेकोरेटर का उपयोग करके पूर्वनिर्धारित राज्यों में परिवर्तन को ट्रैक करें।

github.com/adamhaney/django-ondelta - django- मॉडल के लिए एक प्रवेश-पत्र जो आपको मॉडल के क्षेत्रों में परिवर्तन को संभालने की अनुमति देता है। अपने स्वयं के स्वच्छ _ * - मॉडल विधियों की शैली में एक एपीआई प्रदान करता है । वर्णन ठीक वैसा ही करता है।

एक अन्य दृष्टिकोण वहाँ प्रस्तावित किया गया था - व्यापार तर्क से संबंधित सभी कोड को एक अलग मॉड्यूल में सार करने के लिए। उदाहरण के लिए, कीमतों के आवेदन में, हम प्रसंस्करण मॉड्यूल में मूल्य प्रसंस्करण के लिए जिम्मेदार सभी कोड का चयन करते हैं। Utils.py दृष्टिकोण के समान, यह अलग है कि हम व्यापार तर्क को सार करते हैं, और सब कुछ नहीं।

अपनी स्वयं की परियोजनाओं में, मैं आमतौर पर लेख के लेखक के दृष्टिकोण का उपयोग करता हूं, निम्नलिखित तर्क का पालन करता है:

• मॉडल विधि में कोड - यदि कोड मॉडल के एक विशिष्ट उदाहरण को संदर्भित करता है
• प्रबंधक विधि में कोड - यदि कोड पूरे प्रासंगिक तालिका को प्रभावित करता है
• प्रपत्र विधि में कोड - यदि कोड सत्यापन और / या अनुरोध से डेटा प्रीप्रोसेस करता है
• सीबीवी विधि में कोड वह है जो अनुरोध पर और अवशिष्ट सिद्धांत द्वारा लागू होता है
• Utils.py में - कोड सीधे परियोजना से संबंधित नहीं है

क्या हम इसकी चर्चा करेंगे?