मैं प्रसंस्करण भुगतान की देखभाल करने के लिए Braintree API for .NET के साथ काम कर रहा हूं। उनका व्यवसाय प्रसंस्करण भुगतान का एक अच्छा काम करता है और एपीआई रैपर सीधे उपयोग के लिए काम करता है। हालांकि, प्रदान की गई एपीआई रैपर निकट जांच या अधिक सख्त उपयोग पर जल्दी विफल होने लगती है; उदाहरण के लिए, इसमें हाथ से लुढ़का enum एस शामिल है। मेरी समस्या यूनिट परीक्षण के साथ आता है जो मेरे रैपर का उपयोग करता है।अवांछनीय ब्रेनट्री एपीआई: क्या मुझे स्रोत कोड बदलना चाहिए या व्यक्तिगत रूप से हर वर्ग को लपेटना चाहिए?
ऐसा करने के लिए, मुझे अनिवार्य रूप से अपने स्वयं के 'नकली' ब्रेनट्री गेटवे का नकल करने की आवश्यकता है जिसमें इसमें कुछ ज्ञात मूल्य होंगे, अनुरोध किए जाने पर त्रुटियां उत्पन्न होंगी। आदि। हमले की मेरी योजना को कार्यक्षमता को ओवरराइड करना था ब्रेनट्री एपीआई रैपर और स्थानीय इन-मेमोरी एंडपॉइंट के अनुरोधों को दोबारा दोहराएं। फिर मैं रनटाइम पर उचित गेटवे/रैपर को जोड़ने के लिए निर्भरता इंजेक्शन का उपयोग कर सकता था।
प्रारंभ में, यह तैराकी से चल रहा था: एपीआई रैपर में किए गए सॉफ़्टवेयर इंजीनियरिंग के खिलाफ पापों के बावजूद, मुझे जिस विधि को ओवरराइड करने की आवश्यकता होगी, उसे चमत्कारिक रूप से virtual चिह्नित किया गया था। हालांकि, यह एक डरावना ठहराव आया: एपीआई रैपर में लगभग कन्स्ट्रक्टर internal चिह्नित किया गया है। इस प्रकार, मैं न तो इन वर्गों से वंचित रह सकता हूं और न ही उन्हें परीक्षण के लिए स्टोर करने के लिए तैयार कर सकता हूं।
एक तरफ: मैं internal रचनाकारों को ग्रोक करता हूं, और कारणों से कि वे वैध रूप से उनका उपयोग करना चाहते हैं। हालांकि, मैंने इसके लिए स्रोत कोड देखा है, और प्रत्येक internal कन्स्ट्रक्टर केवल मामूली संपत्ति असाइनमेंट करता है। इस प्रकार, मैं दावा करने में सहज हूं कि एक अलग कोडिंग अभ्यास का पालन किया जाना चाहिए था।
तो, मैं अनिवार्य रूप से तीन विकल्प के साथ छोड़ दिया है:
खरोंच से मेरे अपने एपीआई आवरण लिखें। यह स्पष्ट रूप से करने योग्य है, और इसका लाभ यह है कि यह एक अच्छी तरह से इंजीनियर बुनियादी ढांचा पैदा करेगा। हालांकि, नुकसान संक्षेप में सूची में बहुत अधिक हैं।
एपीआई से स्रोत कोड खींचें और इसे मेरे समाधान में शामिल करें। मैं उन सभी
internalरचनाकारों को बदल सकता हूं जो मुझे उन्हें काम करने के लिए आवश्यक हैं। नुकसान यह है कि मुझे प्रत्येक आगामी एपीआई रैपर रिलीज पर इन सभी परिवर्तनों को फिर से अपडेट करना होगा।पूरे एपीआई रैपर में उपयोग करने के लिए आवश्यक प्रत्येक ऑब्जेक्ट के लिए रैपर कक्षाएं लिखें। यह प्रदत्त स्रोत कोड को बदलने का लाभ नहीं रखता है; नुकसान बड़े हैं, हालांकि: अनिवार्य रूप से रैपर में प्रत्येक कक्षा को तीन बार फिर से लिखना (एक इंटरफ़ेस, एक ब्रेनट्री एपीआई रैपर एडाप्टर, और एक टेस्टेबल संस्करण)।
दुर्भाग्यवश, उन सभी को चूसना। मुझे लगता है कि विकल्प 2 विकल्पों में से कम से कम खराब हो सकता है, लेकिन यह मुझे गंदा महसूस करता है। क्या किसी ने इस समस्या को हल किया है/बेहतर, अधिक टेस्टेबल रैपर लिखा है? यदि नहीं, तो क्या मैंने कार्रवाई के संभावित पाठ्यक्रम को याद किया है? यदि नहीं, तो उन तीन विकल्पों में से कौन सा कम से कम अशिष्ट लगता है?
हाँ, यह ऐसा करेगा। धन्यवाद – eouw0o83hf