मेरे पास पाइथन/पीईक्यूटी में लिखा गया एक बहुत ही डेटा केंद्रित एप्लिकेशन है। मैं की योजना बना रहा हूं ताकि वास्तव में कोर से UI को अलग करने के लिए कुछ रिफैक्टरिंग कर सकें, मुख्य रूप से क्योंकि अभी तक कोई वास्तविक परीक्षण नहीं है, और स्पष्ट रूप से इसे बदलना है।रिफैक्टरिंग
पहले से ही कुछ अलगाव है, और मुझे लगता है कि मैंने कुछ चीजें सही तरीके से की हैं, लेकिन यह बिल्कुल सही नहीं है। दो उदाहरण के लिए, आप को दिखाने के लिए चीजों को किस तरह मुझे परेशान कर रहे हैं:
जब एक डेटा वस्तु का प्रतिनिधित्व पर उपयोगकर्ता को राइट-क्लिक, संदर्भ मेनू पॉप अप होने वाले डेटा वस्तु द्वारा बनाई गई है, हालांकि यह डेटा ऑब्जेक्ट (अनिवार्य रूप से डेटाबेस पंक्ति का ORM प्रतिनिधित्व) स्पष्ट रूप से UI के साथ कुछ भी नहीं करना चाहिए।
जब डेटाबेस में कुछ लिखा जाता है, लेकिन लेखन विफल रहता है (उदाहरण के लिए डेटाबेस रिकॉर्ड किसी भिन्न उपयोगकर्ता द्वारा लॉक किया गया है), शास्त्रीय "पुनः प्रयास/निरस्त करें" संदेश बॉक्स उपयोगकर्ता को प्रस्तुत किया जाता है। यह संवाद डेटा प्रदाता * द्वारा बनाया गया है, हालांकि प्रदाता को स्पष्ट रूप से कोई UI कार्यक्षमता नहीं होनी चाहिए। स्पष्ट रूप से, प्रदाता इसके बजाय अपवाद बढ़ा सकता है या अन्यथा विफलता का संकेत दे सकता है, और यूआई पकड़ सकता है और तदनुसार कार्य कर सकता है।
* यही वह शब्द है जिसका उपयोग मैं उस वस्तु के लिए करता हूं जो मूल रूप से डेटाबेस तालिका का प्रतिनिधित्व करता है और को अपने डेटा ऑब्जेक्ट्स और डेटाबेस इंजन के बीच मध्यस्थ करता है; मुझे यकीन है कि है कि क्या क्या आमतौर पर एक "प्रदाता"
मैं परीक्षण के साथ अनुभव नहीं है कहा जाता है कि नहीं कर रहा हूँ, तो मैं आसानी से नहीं testability समस्याओं या की तरह "लगता है" है, लेकिन इससे पहले कि मैं उसमें प्रवेश करता हूं, कुछ पुनर्गठन करना होता है।
कोई जटिल व्यापार तर्क शामिल (यह मुख्य रूप से बस CRU
डी
है हाँ, यहाँ तक कि डी के बिना), और इस पुनर्लेखन की तुलना में अधिक पुनर्गठन किया जाएगा है, इसलिए मैं की तरह प्रतिगमन कीड़े को शुरू करने के बारे में वास्तव में चिंतित नहीं हूँ this question में चर्चा की।
मेरी योजना इस विचार के साथ रिफैक्टरिंग शुरू करना है कि यूआई भाग को आसानी से के रूप में हटाया जा सकता है, क्यूटी इंटरफेस के बजाय वेब फ्रंटेंड या टेक्स्ट-आधारित इंटरफ़ेस द्वारा प्रतिस्थापित किया जा सकता है। दूसरी ओर, क्यूटी स्वयं भी कोर द्वारा उपयोग किया जाएगा, क्योंकि सिग्नल/स्लॉट तंत्र का उपयोग कुछ स्थानों में किया जाता है, उदा। डेटा ऑब्जेक्ट्स changed सिग्नल को इंगित करने के लिए उत्सर्जित करता है, ठीक है, आप जानते हैं कि क्या।
तो, मेरा प्रश्न: क्या यह टेस्टेबिलिटी और रखरखाव बढ़ाने के लिए एक व्यवहार्य दृष्टिकोण है? कोई अन्य टिप्पणी, विशेष रूप से पाइथन के साथ दिमाग में?
अब यह एक दिलचस्प विचार है, इसे प्यार करो! प्रेषक से संबंधित कोई स्रोत या टिप नहीं है? अर्थात। विभिन्न कार्यान्वयन संभावनाएं, संभावित चेतावनी, अनुभव इत्यादि? – balpha
डिस्पैचर कैश मैनेजर, सत्यापनकर्ता, यूआरएल मैपर जैसे सभी उपप्रणालीओं को सभी एपीआई कॉल पास करेगा ... इसलिए प्रेषक प्रत्येक उपप्रणाली (कुछ नियमों के आधार पर) एपीआई कॉल, संदर्भ, तर्क पास करता है और अंत में एपीआई को आमंत्रित करता है की आवश्यकता है। हमने शुरुआत में उपप्रणाली के पंजीकरण की अनुमति देने के लिए जेनेरिक डिस्पैचर डिज़ाइन करने की कोशिश की लेकिन बाद में प्रेषक के लिए बस गए जिसने उपप्रणाली से निपटने का तरीका बताया है। दुर्भाग्य से यह एपीआई केंद्रित अनुप्रयोगों के लिए ढांचा एक बंद स्रोत है लेकिन प्रभाव प्रत्येक एपीआई के लिए सजावटी के ढेर की तरह कुछ है लेकिन एक निहित तरीके से है। – Shekhar
संदर्भ निर्धारित करने और पास करने के लिए भी बहुत महत्वपूर्ण भूमिका निभाई गई थी। – Shekhar