2009-12-23 16 views
5

पृष्ठभूमि:
मैं उन उपकरणों पर काम कर रहा हूं जो तेजी से बदलते एपीआई पर निर्भर होंगे और तेजी से बदल रहे डेटा मॉडल पर निर्भर होंगे जिन पर मेरा शून्य नियंत्रण होगा।

डेटा मॉडल और एपीआई परिवर्तन आम हैं, यहां मुद्दा यह है कि मेरा कोड वर्तमान और सभी पिछले संस्करणों (यानी 100% बैकवर्ड संगतता) के साथ काम करना जारी रखेगा क्योंकि सभी आंतरिक रूप से उपयोग जारी रहेगा।परिवर्तन सहिष्णुता के लिए सुझाव

यह भी शान से नीचा होना चाहिए जब यह याद आ रही/अज्ञात सुविधाओं आदि

उपकरण सी # WinForms साथ में लिखा जाएगा में चलाता है और परीक्षण कस्टम हार्डवेयर के लिए कर रहे हैं।

<Edit> 

मेरा लक्ष्य केवल सुविधाओं को जोड़ने के लिए और जब डेटा मॉडल परिवर्तन आते हैं, एपीआई संस्करण पर आधारित है कि एक कारखाने के द्वारा बनाई गई हो जाएगी डाटा मॉडल कक्षाओं का एक नया सेट बनाने कक्षाएं बनाने के लिए होने के करीब कुछ होगा ।

मेरे लिए चुनौती यह है कि भविष्य की विशेषताएं विशिष्ट डेटा मॉडल पर निर्भर हो सकती हैं, जिन्हें मिश्रित और मिलान किया जा सकता है (जब तक अंतिम कॉम्बो तक नहीं पहुंच जाता)। आप इसे कैसे सुदृढ़ तरीके से संभालेंगे?

<Edit2> 

बेशक, एक बार एक उत्पाद भेज दिया जाता है, मैं उपकरण पुन: उपयोग करने और सिर्फ नए उत्पादों के लिए कोड जोड़ने के लिए चाहते हैं। इससे पहले कि मैं यहाँ शुरू कर दिया, हर उत्पाद चक्र (खरोंच से) सभी टूलींग, कुछ को फिर से लिखने मैं :) भविष्य में रोकने के लिए लक्ष्य का मतलब

</Edit> 

प्रश्न:
क्या डिजाइन तकनीकों और पैटर्न आप सुझाव है या होता है एपीआई/डेटा मॉडल के कई संस्करणों के साथ संगतता बनाए रखने के साथ सफलता मिली है?

मुझे किस नुकसान के लिए देखना चाहिए?

+0

क्या एपीआई/डेटा मॉडल पुस्तकालय हैं जो जीएसी स्थापित हैं जिन्हें आपको संदर्भित करने की आवश्यकता है, या वे तृतीय पक्ष पुस्तकालय हैं जिन्हें आप अपने ऐप के साथ तैनात करते हैं जो कसकर अन्य सेवाओं के साथ मिलकर हैं? –

+0

यह वास्तव में विभिन्न फर्मवेयर संस्करण हैं जिन्हें अभी भी टूल के साथ काम करने की आवश्यकता है। –

उत्तर

4

व्यावहारिक रूप से सभी ठोस पैटर्न यहाँ लागू होते हैं, लेकिन विशेष रूप Single Responsibility Principle (SRP) और Open/Closed Principle (ओसीपी)।

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

एसआरपी भी बहुत उपयोगी है क्योंकि इसका मतलब है कि यदि कक्षा केवल एक चीज करता है, और वह चीज़ अप्रचलित हो जाती है, तो यह कई अन्य समस्याओं के साथ खींच नहीं पाती है। इसे अपने आप मरने के लिए छोड़ दिया जा सकता है।

एक और अधिक व्यावहारिक स्तर पर, मैं सुझाव है कि आप दो सिद्धांतों का पालन करें: इंटरफेस के खिलाफ

सदस्यों

टीडीडी (या सिर्फ एक व्यापक इकाई परीक्षण सूट) परिवर्तनों को तोड़ने से आपको बचाने में मदद करेगा।

0

अपने कोड और उन चीज़ों के बीच इंटरफ़ेस में अपना स्वयं का रैपर लिखें जो आप नियंत्रित नहीं करते हैं। फिर आप एपीआई के खिलाफ अपना कोड लिख सकते हैं, रैपर का खुलासा होता है, और केवल रैपर में इंटरऑप के बारे में चिंता करने की ज़रूरत है।

0

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

2

आपने बताया कि कोड कस्टम हार्डवेयर का परीक्षण करने के लिए है। क्या आपका कोड (यानी परीक्षण दिनचर्या) भी बदल जाएगा? क्या आपका कोड आज एक सर्कल का परीक्षण करेगा और कल त्रिकोण होगा या उसी मूल सर्कल जो दिन-प्रतिदिन विकसित हो रहा है?

यदि चीजें आगे बढ़ती हैं तो निरंतर बिंदु है तो मैं वहां से शुरू करूंगा और एपीआई और डेटा मॉडल के प्रत्येक संस्करण के लिए रैपर लिखूंगा जो अन्य उत्तरों में सुझाई गई तकनीकों को देखते हुए केंद्र से लिंक होगा।

हालांकि, यदि कोई निरंतर बिंदु नहीं है और सब कुछ चलता है तो मैं परियोजना छोड़ दूंगा! यह नहीं किया जा सकता है!

+0

यह दोनों का एक छोटा सा है ... कुछ बिंदुओं पर गंभीर वास्तुशिल्प परिवर्तन हो सकते हैं, और उन प्रमुख परिवर्तनों के बीच विकासवादी परिवर्तन होंगे। इन सभी को सही ढंग से संभालना होगा। –

+0

बेशक, कुछ बिंदु पर हम विशेष संस्करणों को छोड़ सकते हैं –

+0

चाल एक निश्चित एंकर पॉइंट ढूंढना है जो स्थिर रहेगी।उदाहरण के लिए इंटेल आर्किटेक्चर में मूल 8088 निर्देश सेट स्थिर है और बाकी सब कुछ बदलता है। एक बार जब निर्देश सेट बदल जाता है (उदा। विभिन्न प्रोसेसर) तो सबकुछ काम करना बंद कर देगा और ध्यान देने की आवश्यकता होगी। आवश्यकताओं को तब तक असंभव करना असंभव है जब तक कि आप एक निश्चित बिंदु को इंगित और पिन नहीं कर सकते। एक बार जब आप इसे पाते हैं तो समाधान स्वयं उपस्थित होगा। किसी भी मामले में यह एक बड़ी चुनौती लगता है और मैं आपको शुभकामनाएं देता हूं :) –

1

क्या आपका एपीआई/आपका डेटा मॉडल आपको मेटाडेटा प्रदान करता है? यदि ऐसा है, तो अपने कोड को यथासंभव एपीआई परिवर्तनों से स्वतंत्र बनाने के लिए इसका उपयोग करना एक अच्छा विचार होगा। उदाहरण के लिए, यदि आपके पास डेटा मॉडल स्कीमा का उपयोग करके सामान्य रूप से अपना डेटा मॉडल एक्सेस दिनचर्या उत्पन्न करने का मौका है, तो आपको यह करना चाहिए। बेशक, यह केवल कुछ प्रकार के संचालन के लिए समझ में आता है।

3

एक विचार जो उपयोगी हो सकता है वह एरिक इवांस द्वारा अपनी पुस्तक Domain Driven Design में चर्चा की गई "भ्रष्टाचार विरोधी परत" है - पैटर्न के लिए मुख्य प्रेरणा आपके सिस्टम को किसी अन्य के परिवर्तन (और idiosyncrasies) से अपनाना है।

0

1) कई यूनिट परीक्षण।

जब भी आप कोड का एक टुकड़ा लिखते हैं, कोड है कि भविष्य के संस्करणों के क्रम में पारित करना होगा के लिए इकाई परीक्षण का एक बहुत प्रकाशित में जांच की जानी।

कि परीक्षण कार्यात्मक जरूरतों, यानी के आधार पर कर रहे हैं सुनिश्चित करें कि नहीं फ़ंक्शन कैसे लिखा जाता है, लेकिन अन्य कोड को तोड़ने के क्रम में इसे क्या करना चाहिए।

इससे लोगों को अन्य कोड तोड़ने वाले परिवर्तनों की जांच करने में मदद मिलेगी।

2) सभी एपीआई और डेटा मॉडल के अच्छे औपचारिक विनिर्देश की आवश्यकता है। यह सुनिश्चित करता है कि उन्हें अधिक सावधानी से डिजाइन किया जाएगा, और परिवर्तन बिना किसी विचार या कारण के शून्य में फेंक दिए जाएंगे।

संबंधित मुद्दे