एमवीसी आर्किटेक्चर में डीजेंगो पर विचार करें:एमवीसी (उदाहरण के लिए Django) में अपने भारी तर्क डालने के लिए सबसे अच्छी जगह क्या है?
मेरे पास वर्ष के सर्वश्रेष्ठ कर्मचारी (जटिल तर्क के साथ कोड की 1000 पंक्तियों) की गणना करने का एक तरीका है, मुझे इसे कहां परिभाषित करना चाहिए और इसे कौन कॉल करेगा?
धन्यवाद
जोड़ना अतिरिक्त प्रबंधक तरीकों से "तालिका स्तरीय" अपने मॉडल के लिए कार्यक्षमता जोड़ने के लिए पसंदीदा तरीका है।
year_employee.py)चलें कहते हैं कि तुम एक मॉडल Employee है, इसलिए, आप प्रबंधन के कर्मचारियों के लिए वर्ग बनाना चाहिए:
class EmployeeManager(models.Manager)
def of_the_year(self):
from year_employee import my_calc_func
return my_calc_func()
फिर इस प्रबंधक को अपने मॉडल
class Employee(models.Model):
[...]
objects = EmployeeManager()
उसके बाद आप बस ऐसा कर सकता है:
chosen_employee = Employee.objects.of_the_year()
डीजेंगो के लिए, व्यापार तर्क डालने का सबसे अच्छा स्थान मॉडल के अंदर है। दृश्य व्यापार तर्क से साफ होना चाहिए और केवल डेटा को टेम्पलेट पर प्रदर्शित/प्रस्तुत करने के लिए उपयोग किया जाना चाहिए या दूसरे शब्दों में दृश्य को केवल तर्क देखने के लिए उपयोग किया जाना चाहिए।
django FAQ से:
MVC के बारे में हमारी व्याख्या के अनुसार, "दृश्य" डेटा है कि उपयोगकर्ता के लिए प्रस्तुत हो जाता है वर्णन करता है। यह आवश्यक नहीं है कि डेटा कैसा दिखता है, लेकिन कौन सा डेटा प्रस्तुत किया गया है। दृश्य बताता है कि आप कौन सा डेटा देखते हैं, नहीं कि आप इसे देखते हैं। यह एक सूक्ष्म भेद है।
मॉडल के तहत अपना व्यावसायिक तर्क डालने से, यह आपको इकाई परीक्षण को आसान बना देगा क्योंकि मॉडल HTTP विधियों या प्रसंस्करण के साथ नहीं हैं।
आपके विशिष्ट उदाहरण के संबंध में "वर्ष के सर्वश्रेष्ठ कर्मचारी (जटिल तर्क के साथ कोड की 1000 पंक्तियों) की गणना करने का एक तरीका ... मुझे इसे कहां परिभाषित करना चाहिए और इसे कौन कॉल करेगा?"
उस कोड के लिए, मैं शायद एक नया मॉड्यूल (शायद रैंकिंग.py) बनाउंगा और इसे वहां रखूंगा। इसे कौन कॉल करेगा इस पर निर्भर करता है कि आप इसका उपयोग कैसे करते हैं, लेकिन मुझे लगता है कि इसे आपके विचारों में से एक से बुलाया जाएगा।
मैं उन लोगों से सहमत हूं जो सोचते हैं कि ऐसे तर्क को mod.py फ़ाइलों के भीतर रखा जाना चाहिए। हालांकि, कोड के 1k लाइनों के साथ आपके पास जितना बड़ा है, मॉडल.py फाइलों [मेरे लिए] को अव्यवस्थित करना शुरू कर देगा। मैं किसी दिए गए आवेदन के भीतर इस तरह के कोड को एक अलग फ़ाइल में स्थानांतरित करने के इच्छुक हूं। ऐसा करने में कोई नुकसान नहीं।
यह एक कस्टम अनुप्रयोग है? यदि हाँ व्यापार से दूर तर्क को दूर करने से वास्तव में संभव नहीं है। कभी-कभी आपको इसे असंख्य कारणों से वहां रखना होगा, जिसमें से एक रखरखाव होगी।
इसके अलावा 99.9% मामलों में यूआई के बाहर एक गणना होना चाहिए।
:
जटिल एल्गोरिथ्म और तर्क के साथ तरीकों/कक्षाएं आयोजित करने के लिए एक अलग मॉड्यूल "services.py" को परिभाषित करना।
जैसा कि हम जानते हैं कि कॉल अंततः विचारों से किया जाएगा (जो जानता है कि यह क्या चाहता है) ताकि हम सबसे अच्छा कर सकें मॉडल में एक विधि को कॉल करना जो आंतरिक रूप से सेवा मॉड्यूल से तर्क कहता है, मॉडल डेटा का उपयोग करता है प्रसंस्करण और परिणाम को प्रतिक्रिया पर लिखा जाना चाहिए।
आपके प्रतिक्रियाओं के लिए धन्यवाद।
मैं "skinny controller, fat model" अवधारणा का पालन करने का प्रयास करता हूं (लिंक रेल के लिए विशिष्ट है, लेकिन अवधारणा अभी भी लागू होती है)। सत्र, कुकीज़, फॉर्म इत्यादि से निपटने के अलावा आपके नियंत्रक में इसमें बहुत अधिक कोड नहीं होना चाहिए। आपके ऐप के सभी वास्तविक तर्क आपके मॉडल में रहना चाहिए, जिससे बाद में परीक्षण और पुन: प्रतिक्रिया करना आसान हो जाता है।