स्विंग एमवीसी - घटना प्रस्ताव और डेटा साझाकरण

Question

मैं स्विंग एप्लिकेशन में एमवीसी पैटर्न लागू करने की कोशिश कर रहा हूं। हालांकि मुझे दो प्रमुख मुद्दों का सामना करना पड़ रहा है क्योंकि आपने पैनल के घोंसले का पदानुक्रम किया है। अभिभावक -> बाल -> ग्रैंड चाइल्ड -> ग्रांड ग्रैंड चाइल्ड।

समस्या 1: नियंत्रक के बीच डेटा को कैसे स्थानांतरित करें और देखें कि आपके पास इस तरह के पदानुक्रम कब है? यदि मैं जाता हूं और माता-पिता से बच्चे को डेटा पास करता हूं तो बहुत सारे नकल होंगे और यदि मैं एक बच्चा बदलता हूं तो सभी माता-पिता को बदलाव की आवश्यकता होगी। मैं नहीं चाहता कि विचार सीधे डीबी से डेटा तक पहुंच सकें और मैं डेटा को नियंत्रक के माध्यम से केवल दृश्यों में स्थानांतरित करना चाहता हूं।

समस्या 2: इस तरह के पदानुक्रम में घटनाओं से नियंत्रक को घटनाओं का प्रचार कैसे करें? मैं PropertyChangeListener का उपयोग करने के बारे में सोच रहा हूं। अगर नियंत्रक द्वारा कोई कार्रवाई की जानी है तो देखें FirePropertyChange ईवेंट। नियंत्रक इन घटनाओं के लिए सुनेगा और कुछ कार्रवाई करेगा। लेकिन फिर अगर मैं पदानुक्रम के लिए ऐसा करता हूं तो कोड डुप्लिकेशन होगा।

1. प्रत्येक पैनल के लिए नियंत्रक का उपयोग करने के लिए, लेकिन यह इस तरह से मैं नियंत्रकों के बहुत सारे के साथ खत्म हो जाएगा:

   मैं तीन विचारों कि उपयोगी हो सकता है।

2. मध्यस्थ डिजाइन पैटर्न का उपयोग करें जो दृश्यों और नियंत्रक के बीच संचार प्रदान करेगा।
3. केंद्रीय रिसीवर & नोटिफ़ायर का उपयोग करें जो सभी संपत्ति परिवर्तन घटनाओं को विचारों से सुनेंगे और रुचि रखने वाले नियंत्रकों को सूचित करेंगे। लेकिन यह केवल मेरे दूसरे मुद्दे को हल करेगा:

कृपया तीसरे विचार की तस्वीर रखने के लिए नीचे दिए गए चित्र का संदर्भ लें। दूसरे के मामले में, मध्यस्थ केंद्र में आ जाएगा।

कृपया मूल्यांकन करें और मुझे बताएं कि किसी ने इस तरह के मुद्दे को बेहतर तरीके से लागू किया है या नहीं।

आप एक ViewModel है कि एक और दृश्य मॉडल की एक प्रॉपर्टी वाला हो सकता है:

Answer 1

मैं आपकी समस्या 1 के लिए एक सुझाव है। और आपके कंट्रोलर विधि पर आपको केवल माता-पिता ViewModel प्राप्त करने की आवश्यकता है क्योंकि मॉडल बाइंडर आपके लिए सभी गुणों को बाध्य करेगा।

public class GrandChildViewModel{ 
    public Int32 SelectedDropDownItem { get; set; } 
    public List<Foo> ListOfFoo { get; set; } 
} 

public class ChildViewModel{ 
    public String Name { get; set; } 
    public Int32 Age { get; set; } 
} 
public class FatherViewModel{ 
    public ChildViewModel Child { get; set; } 
    public GrandChildViewModel GrandChild { get; set; } 
} 

यह पदानुक्रम का एक उदाहरण है। आपका दृश्य केवल FatherViewModel का संदर्भ देगा। और आपके नियंत्रक को पिताव्यूमोडेल भी मिलेगा। modelBinder स्वचालित, अपना काम करते अगर आप HTML की तरह बनाने के लिए:

@Html.TextBoxFor(m => m.Child.Name) 

यह इनपुट प्रस्तुत करना होगा:

<input type="text" id="Child_Name" name="Child_Name" /> 

Answer 2

अंक 1: नियंत्रक और दृश्य के बीच डेटा स्थानांतरित करने के लिए कैसे जब आप में ऐसा पदानुक्रम है? यदि मैं जाता हूं और माता-पिता से बच्चे को डेटा पास करता हूं तो बहुत सारे डुप्लिकेशन होंगे और यदि मैं एक बच्चा बदलता हूं तो सभी माता-पिता को परिवर्तन की आवश्यकता होगी। मैं नहीं चाहता कि विचार सीधे डीबी से डेटा तक पहुंच सकें और मैं चाहता हूं कि डेटा को नियंत्रक के माध्यम से केवल दृश्यों में स्थानांतरित किया जाए।

पदानुक्रम को अनदेखा करने और प्रासंगिक नियंत्रक के साथ विचार पंजीकृत करके अधिक रैखिक दृष्टिकोण के लिए जाने के बारे में कैसे? डेटा को मॉडल के माध्यम से किया जा सकता है, जहां से Observer या Listener पैटर्न के माध्यम से परिवर्तन ट्रिगर किए जाएंगे।

इसके साथ आपके पास कोई डुप्लीकेट नहीं होगा। सब कुछ एक मॉडल या मॉडलों की एक श्रृंखला में केंद्रीकृत किया जाएगा। उपयोगकर्ता कार्रवाई या बाहरी घटना के बाद नियंत्रक, या नियंत्रक पंजीकृत दृश्यों की सूची पर अधिसूचना चला सकते हैं।

इसके अलावा, विचारों को निश्चित रूप से डेटा स्रोत तक नहीं पहुंचना चाहिए जैसा आप कहते हैं। यहाँ अमूर्त की कम से कम एक परत होनी चाहिए। यदि आपका नियंत्रक मध्यस्थ पैटर्न का उपयोग करता है जो मैं करता हूं वह एक अतिरिक्त डेटा परत में इंटरफेस के अनुरोधों को अग्रेषित करके इसे संभालता है।

आगे सोचकर, मुझे नहीं लगता कि दृश्य के माध्यम से पंजीकरण करना एक अच्छा विचार होगा। तो मैं इसे अलग रखूंगा। विचारों को हाथ से शुरू करें या आपको आवश्यक विचारों के माध्यम से पुन: प्रयास करने का एक तरीका खोजें। शायद इस तरह के फैक्ट्री के माध्यम से अपने विचार प्राप्त करें जो इस चरण को स्वचालित करते हैं।

समस्या 2: घटनाओं को पदानुक्रम में नियंत्रक से देखने के लिए कैसे प्रसारित करें? मैं PropertyChangeListener का उपयोग करने के बारे में सोच रहा हूँ। देखें फ़ायरप्रॉपर्टी चेंज इवेंट यदि नियंत्रक द्वारा कोई कार्रवाई की जानी है। नियंत्रक इन घटनाओं के लिए सुनेगा और कुछ कार्रवाई करेगा। लेकिन फिर से अगर मैं पदानुक्रम के लिए ऐसा करता हूं तो कोड डुप्लिकेशन होगा।

फिर से, आप एक रैखिक दृष्टिकोण अपना सकते हैं। जब कोई दृश्य पंजीकृत होता है तो नियंत्रक इसे इसके श्रोताओं को जोड़ सकता है। या आप दृश्य को कुछ अर्थपूर्ण स्टाइल संदेश भेज सकते हैं (उदा: डक्शन ("सेव")) जिसे प्रेषण तंत्र के माध्यम से संभाला जा सकता है। आपको यह तय करने के लिए छोड़ देगा कि पैरामीटर कैसे अग्रेषित किए जा सकते हैं।

क्या संपत्तिChangeListeners की आवश्यकता होगी? मेरा मतलब है, क्या आपको उस तरह की ग्रैन्युलरिटी चाहिए?

प्रत्येक पैनल के लिए नियंत्रक का उपयोग करने के लिए, लेकिन यह इस तरह से मैं नियंत्रकों के बहुत सारे के साथ खत्म हो जाएगा:

मैं तीन विचारों कि उपयोगी हो सकता है। मध्यस्थ डिजाइन पैटर्न का उपयोग करें जो विचारों और नियंत्रक के बीच संचार प्रदान करेगा। केंद्रीय रेसीवर & नोटिफ़ायर का उपयोग करें जो सभी संपत्ति परिवर्तन ईवेंट दृश्यों से सुनेंगे और रुचि रखने वाले नियंत्रकों को सूचित करेंगे। लेकिन इस केवल मेरी दूसरी मुद्दे का समाधान होगा:

यह अस्पष्ट HMVC तरह लगता है। इस दृष्टिकोण के साथ आप प्रत्येक उपप्रणाली के लिए मॉडल-व्यू-कंट्रोलर के triads हैं। यह एक दिलचस्प विचार है लेकिन यह गन्दा हो सकता है और यह स्पष्ट नहीं है कि पदानुक्रम कैसे काम करना है और कैसे समन्वय/अधीनता हासिल की जाती है।

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

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

जो भी आप करते हैं, चीजों को यथासंभव सरल बनाने की कोशिश करें। आपको बिना किसी झगड़े के मॉडल और नियंत्रक के साथ एक टेस्ट व्यू करने में सक्षम होना चाहिए।

Answer 3

जब मैं this HMVC Pattern का उपयोग कर समाप्त हुआ तो मुझे इसी तरह का मुद्दा सामना करना पड़ रहा था। हां आप इस अर्थ में सही हैं कि बहुत सारे नियंत्रक होंगे। लेकिन यह भी सच है कि यह आपको कोड में चिंताओं को स्पष्ट रूप से अलग करेगा। आप कुछ एप्लिकेशन विशिष्ट, उच्च स्तरीय समग्र विजेट बनाकर नियंत्रकों की संख्या सीमित कर सकते हैं। इस मामले में, पदानुक्रम अधिकतम 2 या 3 स्तर तक अधिकतम तक सीमित किया जा सकता है और नियंत्रकों को किसी भी माता-पिता/बच्चे को घटनाओं का प्रतिनिधित्व करने के लिए जंजीर बनाया जा सकता है।

एक बार जब आप सर्वर से डेटा लोड कर लेते हैं, तो आप कुछ राहत पाने के लिए सत्र मानचित्र को भी बनाए रख सकते हैं और easy access to frequently required data - हालांकि मैं इसका अधिक समर्थन नहीं करता हूं।

यदि विकास टीम समझती है और इसे ठीक से पालन करती है तो पैटर्न काफी अच्छी तरह से काम करता है।