क्या यह आईओसी के लिए एक सामान्य उपयोग मामला है?

Question

मेरा वर्तमान एप्लिकेशन उपयोगकर्ताओं को कस्टम स्क्रीन के सेट के माध्यम से कस्टम वेब फ़ॉर्म को परिभाषित करने की अनुमति देता है। यह अनिवार्य रूप से एक ईएवी प्रकार का आवेदन है। इस प्रकार, मैं किसी दिए गए पृष्ठ को प्रस्तुत करने के लिए HTML या ASP.NET मार्कअप को हार्ड कोड नहीं कर सकता। इसके बजाए, यूआई सेवा परत से फॉर्म ऑब्जेक्ट का एक उदाहरण अनुरोध करता है, जो बदले में कई आरडीएमबीएस टेबल का उपयोग करके एक बनाता है। फार्म आप इस तरह के एक संदर्भ में देखने की अपेक्षा करेंगे वर्गों की तरह शामिल हैं: Form =>IEnumerable<FormSections> =>IEnumerable<FormFields>

यहाँ सेवा परत की तरह लग रहा है:

public class MyFormService: IFormService{ 

     public Form OpenForm(int formId){ 
      //construct and return a concrete implementation of Form 
     } 
} 

सब कुछ (कुछ समय के लिए) ठाठ से काम करता है । यूआई किसी भी रूप में कोई भी बुद्धिमान नहीं है कि किसी भी रूप में कौन से अनुभाग/फ़ील्ड मौजूद हैं: यह खुशी से फॉर्म ऑब्जेक्ट को एक कार्यात्मक एएसपी.नेट पृष्ठ में प्राप्त करता है।

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

public class MyFormService: IFormService{ 

     public Form OpenFormForEditing(int formId){ 
      //construct and return a concrete implementation of Form 
     } 

     public Form OpenFormForViewing(int formId){ 
      //construct and a concrete implementation of Form 
      //apply additional transformations to the form 
     } 
} 

फिर सब कुछ अच्छा काम करता है और शेष बल को बहाल कर दिया गया। यूआई फॉर्म में क्या है, और हमारे चिंताओं को अलग करने के लिए अज्ञेयवादी है। कुछ ही हफ्ते बाद, व्यवसाय एक नई आवश्यकता बताता है: कुछ परिदृश्यों में, हमें उपरोक्त संदर्भित फॉर्म ट्रांसफॉर्मेशन के केवल कुछ लागू करना चाहिए।

इस बिंदु पर, ऐसा लगता है कि "स्पष्ट विधि" दृष्टिकोण एक मृत अंत तक पहुंच गया है, जब तक कि मैं विधियों के विस्फोट (OpenFormViewingScenario1, OpenFormViewingScenario2, आदि) के साथ समाप्त नहीं करना चाहता। इसके बजाय, मैं अविवेक के एक अन्य स्तर पर परिचय: सतह पर

public interface IFormViewCreator{ 
     void CreateView(Form form); 
} 

public class MyFormService: IFormService{ 

     public Form OpenFormForEditing(int formId){ 
      //construct and return a concrete implementation of Form 
     } 

     public Form OpenFormForViewing(int formId, IFormViewCreator formViewCreator){ 
      //construct a concrete implementation of Form 
      //apply transformations to the dynamic field list 
      return formViewCreator.CreateView(form); 
     } 
} 

, इस स्वीकार्य दृष्टिकोण की तरह लगता है और अभी तक वहाँ एक निश्चित गंध है। अर्थात्, यूआई, जो OpenFormForViewing के कार्यान्वयन विवरण के बारे में अज्ञानी आनंद में रह रहा था, के पास IFormViewCreator का एक उदाहरण होना चाहिए और उसका निर्माण होना चाहिए।

1. मेरे सवालों का दुगना कर रहे हैं: वहाँ composability मैं के बाद कर रहा हूँ प्राप्त करने के लिए एक बेहतर तरीका है? (शायद 0oकंक्रीट IFormViewCreator बनाने के लिए एक आईओसी कंटेनर या घर लुढ़का कारखाने का उपयोग कर द्वारा?
2. क्या मैंने मूल रूप से अमूर्तता को खराब कर दिया था?

Answer 1

जैसा कि मैं सवाल समझता हूं, आपको UI परत पर इसे भेजने से पहले फ़ॉर्म को संशोधित करने की आवश्यकता है। यह मुझे लगता है कि Decorator की जगह होगी। IFormViewCreator के बिना पुराने IFormService इंटरफ़ेस को रखें।

अब आप वांछित फ़िल्टरिंग या संशोधन को लागू करने वाले एक या अधिक सजावटी फॉर्म सेवा (ओं) बना सकते हैं।

public class MyDecoratingFormService : IFormService 
{ 
    private readonly IFormService formService; 

    public MyDecoratingFormService(IFormService formService) 
    { 
     if(formService == null) 
     { 
      throw new ArgumentNullException("formService"); 
     } 

     this.formService = formService; 
    } 

    public Form OpenFormForEditing(int formId) 
    { 
     var form = this.formService.OpenFormForEditing(formId); 
     return this.TransformForm(form); 
    } 

    public Form OpenFormForViewing(int formId) 
    { 
     var form = this.formService.OpenFormForViewing(formId); 
     return this.TransformForm(form); 
    } 

    public Form TransformForm(Form form) 
    { 
     // Implement transformation/filtering/modification here 
    } 
} 

अब आप अपने मूल IFormService कार्यान्वयन को ऐसे एक या अधिक सजावट के साथ सजाने के लिए तैयार कर सकते हैं।

IFormService formService = new MyDecoratingFormService(new MyFormService()); 

आप के रूप में कई डेकोरेटर (अपनी जिम्मेदारी के साथ प्रत्येक) चाहें, उतनी बार एक दूसरे के आसपास लपेट कर सकते हैं।

ऐसा करने के लिए डी कंटेनर की कोई स्पष्ट आवश्यकता नहीं है, लेकिन यह अन्य डी पैटर्न के साथ अच्छी तरह से फिट बैठता है। मैं डेकोरेटर हर समय :)

Answer 2

का उपयोग जब तक मैं तरीकों (OpenFormViewingScenario1, OpenFormViewingScenario2, आदि) का एक विस्फोट के साथ खत्म करना चाहते हैं।

आप निहित आवश्यकताओं की जटिलता नहीं निकाल सकते। एक तरफ या दूसरा, आपको उपयोग के मामले का पता लगाने और तदनुसार कार्य करने की आवश्यकता होगी।

आप सभी संभव संयोजनों को सूचीबद्ध कर सकते हैं या समझदारी से प्रसंस्करण को कारगर करने का प्रयास कर सकते हैं - यदि यह संभव है। उदाहरण के लिए, यदि आवश्यकता की प्रकृति के कारण N * M = X संभावनाएं हैं, तो X विधियों की विस्तृत सूची वास्तव में अच्छी नहीं है। N और M मामलों की संरचना से X संभावित रूपों को बनाने के लिए आपको कारक होना चाहिए।

सटीक आवश्यकता को जानने के बिना यह कहना मुश्किल है। फिर ऐसी रचना को कारक करने के कई संभावित तरीके हैं, उदा। सजावटी, चेनऑफ रिस्पॉन्सबिलिटी, फ़िल्टर, आदि जटिल तर्क लिखने के सभी तरीके हैं।

अर्थात्, यूआई, जो OpenFormForViewing की कार्यान्वयन विवरण के बारे में अनभिज्ञ आनंद में रह रही थी, की ज्ञान के अधिकारी और IFormViewCreator का एक उदाहरण बनाना होगा।

प्रस्तुति को कहीं और बनाए गए फॉर्म को सौंप दिया जाना चाहिए, ताकि फॉर्म निर्माण से अज्ञेय बने रहें। हालांकि फॉर्म को कहीं भी इकट्ठा/बनाया जाना चाहिए।

एमवीसी में, ऐसा तर्क नियंत्रक में जाता है जो मॉडल/फॉर्म को अपडेट करेगा और सही दृश्य/प्रतिपादन को प्रेषित करेगा। अच्छे प्रश्न के लिए एएसपी.NET