🎽 👨🏿‍🔬 ⌚️ MVVM पैटर्न और पेज नेविगेशन 👩🏽‍🤝‍👨🏿 👩🏻‍🔬 🚋

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

परिचय

हर कोई जो पहले से ही WPF के साथ काम कर चुका है, वह शायद MVVM पैटर्न (लेख के अंत में दिए गए लिंक) से परिचित है। आखिरकार, एमवीवीएम की अवधारणा सीधी है और, कम से कम, इसके उपयोग के लाभ को सहज रूप से समझा जाना चाहिए। यदि आप चाहते हैं कि यह स्वयं को इसकी सभी महिमाओं में दिखाए, तो उपयोगकर्ता नियंत्रण (UserControl) के "कोड बिहाइंड" में जितना संभव हो उतना कम तर्क रखें और किसी भी स्थिति में ViewModel के अंदर UI के लिए सीधे लिंक का उपयोग न करें। यह दृष्टिकोण आपको नियंत्रण से अलग ViewModel का परीक्षण करने की क्षमता के रूप में एक बड़ा लाभ देगा। एक और अच्छा अभ्यास सीधे नियंत्रण में ViewModel के उदाहरणों के निर्माण को कम करना है। यह ठीक है अगर नियंत्रण खुद के लिए एक विशेष प्रकार का एक ViewModel बनाता है - इस मामले में नियंत्रण में किसी प्रकार की परीक्षण गुड़िया डालना मुश्किल होगा। अन्यथा, चीजें तब होंगी जब एक निश्चित अभिभावक नियंत्रण बाकी स्क्रीन के लिए ViewModels बनाने में व्यस्त है, क्योंकि तब कोड स्पेगेटी के एक अस्थिर गुच्छा में बदल सकता है। यदि अन्य ViewModels ViewModels बनाने के लिए जिम्मेदार हैं, तो परीक्षण करना बहुत आसान होगा।

आइए एक नेविगेशन बार, कई स्क्रीन और डायलॉग बॉक्स के साथ एक एप्लिकेशन की कल्पना करें। कुछ इसी तरह नीचे प्रस्तुत किया गया है।

हम कई इकाइयां बना सकते हैं: मुख्य विंडो, बटन के साथ नेविगेशन बार, वर्तमान पृष्ठ और इस पृष्ठ के ऊपर संवाद। हमारे आवेदन में, हम पेजिंग के लिए हाइपरलिंक का उपयोग कर सकते हैं, बजाय बटन के बजाय सामग्री के रूप में हाइपरलिंक के साथ टेक्स्टब्लॉक का उपयोग करने के लिए। हाइपरलिंक में एक संपत्ति है जो फ़्रेम के नाम को इंगित करती है जिसमें एक नए पृष्ठ पर कूदना है। और सब कुछ ठीक लग रहा है, लेकिन हाइपरलिंक का उपयोग करके वांछित ViewModel को पेज पर स्थानांतरित करना मुश्किल लगता है।
मैंने नेट पर इस समस्या के कुछ हल देखे:

कोड एप्लिकेशन के माध्यम से मुख्य एप्लिकेशन विंडो में फ़्रेम.नएवीगेटेड इवेंट में, आप फ़्रेम में लोड की गई सामग्री तक पहुंच सकते हैं और कोड कोड व्यू व्यूहेल में बनाए गए कोड से इसे संलग्न कर सकते हैं। इस प्रकार, सभी पृष्ठों के लिए ViewModels का निर्माण एक हैंडलर में लंबे समय तक उपयोग करने पर केंद्रित होगा ... और यदि ... या स्विच। इस तथ्य के बारे में कि इस तरह के "हार्ड कोडेड" नेविगेशन प्रक्रिया का परीक्षण स्वचालित रूप से करना बहुत मुश्किल है, मैं चुप हूं।
एक अन्य उपाय यह है कि इसके तहत पेज और ViewModel का एक उदाहरण बनाया जाए, PageM के DataContext में ViewModel को एम्बेड करें और बनाए गए पेज के स्थानांतरण के साथ फ़्रेम पर नेविगेट करें पर कॉल करें। यह समाधान पिछले एक की तुलना में थोड़ा बेहतर है, लेकिन अभी भी सभी "एमवीवीएम-वे" नहीं है।
तीसरा समाधान PRISM पुस्तकालयों का उपयोग करना है। यह समग्र यूआई को लागू करने के लिए बड़े उद्यम अनुप्रयोग क्षेत्र में उपयोग किया जाता है। यदि आप AngularJS से परिचित हैं, तो आप समझेंगे कि यह क्या है। एक निश्चित क्षेत्र प्रबंधन कार्यान्वित किया जाता है, जिसमें UI के कुछ भाग पंजीकृत होते हैं। फिर, बनाए गए प्रबंधक के माध्यम से, नियंत्रण का उदाहरण एक निश्चित उपनाम द्वारा कहा जाता है, साथ ही आवश्यक डेटा संदर्भ का असाइनमेंट भी। यह कार्यक्षमता उसी तरह की है जो पहले से ही नेवीगेशन सर्विस WPF में लागू है।

पहले दो निर्णय एक स्पष्ट बैसाखी हैं। PRISM एक संपूर्ण UI संरचना है। बेशक, इसके अध्ययन में निवेश करने लायक है, लेकिन छोटे अनुप्रयोगों (उदाहरण के लिए अवधारणा का प्रमाण) के लिए, आईओसी और पीआरआईएसएम जैसी चीजों का उपयोग करना व्यावहारिक नहीं हो सकता है।

एमवीवीएम के संदर्भ में कौन सा सरल समाधान कम या ज्यादा आसानी से फिट हो सकता है? सिल्वरलाइट में पेज क्लास में एक OnNavigatedTo ओवरलोड विधि है। इस पद्धति में, नेविगेशन पैरामीटर के लिए ViewModel को पारित करना सुविधाजनक होगा। दूसरे पैरामीटर के रूप में नेविगेट करें (Uri uri, ऑब्जेक्ट नेविगेशनकनेक्ट)। हालांकि, WPF में, पेज नहीं है। कम से कम मुझे यह या इसके समकक्ष कुछ नहीं मिला। हमें एक निश्चित मध्यस्थ की आवश्यकता है या, यदि आप चाहें, तो एक प्रबंधक जो पेज नेविगेशन को नियंत्रित करेगा और आवश्यक व्यूमॉडल को विधि पैरामीटर से DataContext में स्थानांतरित करेगा। इस तरह के एक नेविगेशन प्रबंधक के कार्यान्वयन पर इस लेख में चर्चा की जाएगी।
अगले भाग में, मैं मुख्य समाधान के कार्यान्वयन के बारे में बात करूंगा, नेविगेशन प्रबंधक के बारे में। फिर, हम यूआई और व्यूमॉडल परतों पर लागू होने की आवश्यकता के बारे में बात करेंगे। समय बचाने के लिए, आप "नेविगेशन प्रबंधक" अनुभाग पढ़ सकते हैं, और अपनी समस्याओं को हल करने के दौरान बाकी को सोच सकते हैं।
कोई भी कोड को तुरंत देखने का इच्छुक व्यक्ति GitHub के रिपॉजिटरी में जा सकता है ।

नेविगेशन प्रबंधक

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

एकाकी वस्तु

#region Singleton private static volatile Navigation instance; private static object syncRoot = new Object(); private Navigation() { } private static Navigation Instance { get { if (instance == null) { lock (syncRoot) { if (instance == null) instance = new Navigation(); } } return instance; } } #endregion

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

 Navigation.Instance.Service

के बजाय

 Navigation.Service

वह विकल्प चुनें जो आपको सबसे अच्छा लगे। ऐसा लगता है कि अंतिम विकल्प सरल है, लेकिन इसके लिए स्थैतिक गुणों और विधियों के अतिरिक्त कार्यान्वयन की आवश्यकता है। इसलिए, नई कार्यक्षमता के कार्यान्वयन के साथ यह उदाहरण संपत्ति (नेविगेशन.इनस्टांस) खोलने के लिए अधिक लाभदायक हो सकता है।

इस सिंगलटन में सेवा गुण फ़्रेम इंस्टेंस के नेवीगेशन सर्विस का एक संदर्भ संग्रहीत करेगा जिसमें पेज ट्रांज़िशन की आवश्यकता होती है। आप इस लिंक के वर्तमान मूल्य को एप्लिकेशन स्टार्टअप (मुख्य विंडो के लोड किए गए ईवेंट हैंडलर में) और नेविगेशन विधियों में से किसी एक को कॉल करने से पहले किसी भी अन्य क्षण में असाइन कर सकते हैं।

उदाहरण

  public MainWindow() { InitializeComponent(); Loaded += MainWindow_Loaded; } void MainWindow_Loaded(object sender, RoutedEventArgs e) { Navigation.Navigation.Service = MainFrame.NavigationService; DataContext = new MainViewModel(new ViewModelsResolver()); }

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

वर्तमान कार्यान्वयन में, प्रबंधक बहुत सरलता से काम करता है। निजी क्षेत्र को एक नया मान प्रदान करने के अलावा, नेविगेशन सेवा के सेटर में, एक सदस्यता समाप्त और नेविगेट की गई सेवा घटना के लिए एक सदस्यता बनाई जाती है।

नेविगेशन सेवा संपत्ति

  public static NavigationService Service { get { return Instance._navService; } set { if (Instance._navService != null) { Instance._navService.Navigated -= Instance._navService_Navigated; } Instance._navService = value; Instance._navService.Navigated += Instance._navService_Navigated; } }

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

निम्नलिखित सार्वजनिक नेविगेशन विधियाँ हैं।

नेविगेशन के तरीके

  #region Public Methods public static void Navigate(Page page, object context) { if (Instance._navService == null || page == null) { return; } Instance._navService.Navigate(page, context); } public static void Navigate(Page page) { Navigate(page, null); } public static void Navigate(string uri, object context) { if (Instance._navService == null || uri == null) { return; } var page = Instance._resolver.GetPageInstance(uri); Navigate(page, context); } public static void Navigate(string uri) { Navigate(uri, null); } #endregion

उपरोक्त कोड में, आप " _resolver " के उपयोग को देख सकते हैं। IoC सेक्शन में, मैं उसके बारे में बात करूँगा। संक्षेप में, कन्टेनर ऑफ कंट्रोल के लिए कंटेनर का यह सबसे सरल कार्यान्वयन है।

नेविगेशन प्रबंधक नेविगेशनस् सेवा से नेविगेशन विधियों के सबसेट को लागू करता है, जो कि अधिकांश सरल मामलों के लिए पर्याप्त है। यह केवल लैंडिंग पृष्ठ के DataContext संपत्ति में प्रेषित ViewModel संलग्न करने के लिए बनी हुई है। यह नेविगेट किए गए ईवेंट हैंडलर में किया जाता है (नीचे कोड देखें)।

नेविगेट किए गए ईवेंट को संभालना

  #region Private Methods void _navService_Navigated(object sender, NavigationEventArgs e) { var page = e.Content as Page; if (page == null) { return; } page.DataContext = e.ExtraData; } #endregion

फ़्रेम प्रकार को पृष्ठ प्रकार पर कास्ट करने के लिए नेविगेट किए गए ईवेंट हैंडलर में प्रयास किया जाता है। इस प्रकार, केवल पेज पर किए जाने वाले बदलावों पर कार्रवाई की जाएगी। अन्य सभी को फ़िल्टर किया जाता है। यदि आप चाहें, तो आप इस "लोहे के पर्दे" को हटा सकते हैं। सफल कास्टिंग के मामले में, घटना के तर्कों के एक्स्ट्राडेटा संपत्ति में पारित ViewModel का उदाहरण लैंडिंग पृष्ठ के DataContext में रखा जाएगा। यह नेविगेशन मैनेजर के बारे में है।
यह पन्नों के कार्यान्वयन और विधानसभा ViewModel'ey के साथ एक विधानसभा बनाने के लिए बनी हुई है। मैंने हेल्पर्स असेंबली भी लागू की, जिसमें मैंने ViewModel के लिए RelayCommand कार्यान्वयन कोड पोस्ट किया। यदि आपके पास ताकत और समय है, तो UI और ViewModel के कार्यान्वयन के विवरण के साथ अगले अनुभागों पर जाएं। यदि नहीं, तो संक्षेप में इस बात की रूपरेखा तैयार करें कि और क्या लागू करने की आवश्यकता है।
प्रत्येक पृष्ठ के लिए, एक अलग ViewModel बनाएं। ये "निजी" ViewModels " नियंत्रण के व्युत्क्रम " ( IoC अनुभाग देखें) का उपयोग करके अपने मूल MainViewModel में त्वरित किया जाता है। मुख्य ViewModel को मुख्य विंडो के DataContext में रखा गया है, लेकिन उसी सफलता के साथ इसे मुख्य विंडो के संसाधन विंडो में या यहां तक कि पूरे एप्लिकेशन स्तर पर एक स्थिर XAML संसाधन के रूप में इंस्टैंट किया जा सकता है। इस स्थिति में, आपको DataContext के लिए बाइंडर्स में Source = {StaticResource MainViewModelDataSourceKey} जैसा कुछ निर्दिष्ट करना होगा। लेकिन फिर इस बारे में चिंता करना संभव नहीं होगा कि तार्किक माता-पिता के DataContext को विरासत में मिला है या नहीं।
MainViewModel में, मैंने कई कमांड बनाए। CommandParameter में निर्दिष्ट पृष्ठ के स्ट्रिंग उपनाम में नेविगेट करने के लिए एक (डेटा संदर्भ को पारित किए बिना नेविगेट करना)। अन्य आदेशों में, उनके निष्पादित प्रतिनिधि में, कमांडपैरमीटर के माध्यम से प्राप्त डेटा संदर्भ के साथ लैंडिंग पृष्ठ के एक विशिष्ट उपनाम के लिए छलांग है। विवरण के लिए, आप गिटहब जा सकते हैं या इस लेख को पढ़ना जारी रख सकते हैं।

ViewModels विधानसभा

यह असेंबली ViewModel का परिचय देती है, जो INotifyPropertyChanged को लागू करती है।

BaseViewModel

  public class BaseViewModel : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected void RaisePropertyChanged(string propertyName) { if (string.IsNullOrWhiteSpace(propertyName)) { return; } if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } }

शेष ViewModels इसे विरासत में मिला है और वर्तमान में बेहद सरल है। वे एक अद्वितीय नाम के साथ एक स्ट्रिंग संपत्ति रखते हैं (नीचे उदाहरण देखें)।

  public class Page1ViewModel : BaseViewModel { public string Page1Text { get { return "Hello, world!\nSent from my iPage 1..."; } } }

टिप्पणी

यहाँ नोटिस संपत्ति केवल पढ़ने के लिए है और बिना RaisePropertyChanged (...) को कॉल किए बिना। इस मामले में, यह सरलता के लिए किया गया था। व्यवहार में, ViewModels के ऐसे गुण पाए जाते हैं, लेकिन अक्सर, क्योंकि ऐसे गुणों पर बंधन केवल एक बार काम करेगा। यहां तक कि अगर मैं RaisePropertyChanged (...) के बिना एक सेटर जोड़ता हूं, तो भी बंधन "एक बार" होगा।

MainViewModel पहले से ही बहुत अधिक जटिल है। जैसा कि मैंने पिछले भाग में संक्षेप में लिखा था, यह निजी ViewModels को संग्रहीत करेगा और नेविगेशन कमांड को लागू करेगा। मेरे मामले में, निजी ViewModels केवल एक बार तथाकथित " रिज़ॉल्वर " का उपयोग करके बनाया जाता है, जब MainViewModel को आरंभ करता है। इसलिए, मैंने केवल इन ViewModels के गेटर्स को लागू किया।

  public Page1ViewModel Page1ViewModel { get { return _p1ViewModel; } } public Page2ViewModel Page2ViewModel { get { return _p2ViewModel; } } public Page3ViewModel Page3ViewModel { get { return _p3ViewModel; } }

फ़ील्ड MainViewModel निर्माता में आरंभीकृत हैं:

  _p1ViewModel = _resolver.GetViewModelInstance(Page1ViewModelAlias); _p2ViewModel = _resolver.GetViewModelInstance(Page2ViewModelAlias); _p3ViewModel = _resolver.GetViewModelInstance(Page3ViewModelAlias);

टिप्पणी

इस मामले में " _resolver " प्रबंधन के व्युत्क्रम का एक और कंटेनर है, जिस पर संबंधित अनुभाग में चर्चा की जाएगी। फिलहाल, यह रिज़ॉल्वर केवल उस उपनाम से एक प्रतिनिधि को निकाल रहा है जो पारित उर्फ व्यूमॉडल से मेल खाता है। यह भी ध्यान देने योग्य है कि व्यवहार में, आपको निजी ViewModels के लिए फ़ील्ड और गुणों का पूर्ण कार्यान्वयन करने की आवश्यकता हो सकती है। यह पहले से ही प्राथमिक रूप से किया जा रहा है।

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

टीम का क्रियान्वयन

  public ICommand GoToPathCommand { get { return _goToPathCommand; } set { _goToPathCommand = value; RaisePropertyChanged("GoToPathCommand"); } } public ICommand GoToPage1Command { get { return _goToPage1Command; } set { _goToPage1Command = value; RaisePropertyChanged("GoToPage1Command"); } } private void InitializeCommands() { GoToPathCommand = new RelayCommand<string>(GoToPathCommandExecute); GoToPage1Command = new RelayCommand<Page1ViewModel>(GoToPage1CommandExecute); GoToPage2Command = new RelayCommand<Page2ViewModel>(GoToPage2CommandExecute); GoToPage3Command = new RelayCommand<Page3ViewModel>(GoToPage3CommandExecute); } private void GoToPathCommandExecute(string path) { if (string.IsNullOrWhiteSpace(path)) { return; } var uri = new Uri(path); Navigation.Navigate(uri); } private void GoToPage1CommandExecute(Page1ViewModel viewModel) { Navigation.Navigate(Navigation.Page1Alias, Page1ViewModel); }

कृपया ध्यान दें कि लैंडिंग पृष्ठ का उपनाम मार्ग के रूप में पारित किया गया है। मैंने इन एलियासेस को नेविगेशन मैनेजर में स्थिरांक के रूप में रखा, लेकिन सामान्य रूप से XML सेटिंग्स फ़ाइल में या किसी प्रकार के पाठ शब्दकोश में उनके लिए सबसे अच्छी जगह है।

GoToPage1Command कमांड को निष्पादित करने के बाद, उपयोगकर्ता को निर्दिष्ट उपनाम द्वारा पृष्ठ पर पुनर्निर्देशित किया जाएगा, और Page1ViewModel का लिंक पेज के DataContext में डाला जाएगा। इस प्रकार, हमें लैंडिंग पृष्ठ से डेटा वापस पाने के लिए अतिरिक्त तर्क को लागू करने की आवश्यकता नहीं है। यह हमारे MainViewModel के अंदर रिपॉजिटरी के साथ काम करेगा, इसलिए हमें वापस जाने से पहले स्वचालित रूप से सभी परिवर्तन प्राप्त होंगे।
सब कुछ ViewModels के साथ होने लगता है। हम यूआई पास करते हैं।

मुख्य विंडो और पेज असेंबली

मुझे सुविधा के लिए फिर से एक परीक्षण आवेदन दें।

बाईं ओर चार बटन हैं। पहला बटन GoToPathCommand कमांड से जुड़ा हुआ है और एक डेटा संदर्भ के बिना Page1 के लिए कूदता है। डेटा संदर्भ के बिना एक पृष्ठ पर जाने के बाद, ViewModel से वर्तमान मान को बाइंडिंग ऑब्जेक्ट के FallbackValue पैरामीटर से मान के साथ बदल दिया जाएगा। शेष बटन कमांड प्रतिनिधि में निर्दिष्ट आवश्यक पृष्ठ पृष्ठ के उपनाम के साथ "निजी" कमांड से बंधे हैं।

मुख्य विंडो का लेआउट और कोड

 <Window x:Class="Navigator.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="480" Width="640"> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto"/> <ColumnDefinition /> </Grid.ColumnDefinitions> <ScrollViewer HorizontalScrollBarVisibility="Disabled" VerticalScrollBarVisibility="Hidden"> <StackPanel> <Button Content="P 1 w/o data" Command="{Binding GoToPathCommand}" CommandParameter="pack://application:,,,/Pages;component/Page1.xaml"/> <Button Content="Page 1" Command="{Binding GoToPage1Command}" CommandParameter="{Binding Page1ViewModel}"/> <Button Content="Page 2" Command="{Binding GoToPage2Command}" CommandParameter="{Binding Page2ViewModel}"/> <Button Content="Page 3" Command="{Binding GoToPage3Command}" CommandParameter="{Binding Page3ViewModel}"/> </StackPanel> </ScrollViewer> <Frame x:Name="MainFrame" Grid.Column="1" Background="#CCCCCC"/> </Grid> </Window>

  public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); Loaded += MainWindow_Loaded; } void MainWindow_Loaded(object sender, RoutedEventArgs e) { Navigation.Service = MainFrame.NavigationService; DataContext = new MainViewModel(); } }

पेज असेंबली में चार पेज होते हैं: पेज 1, पेज 2, पेज 3, पेज404। पहले दो बस इसी निजी ViewModel की संपत्ति से जुड़े पाठ ब्लॉक होते हैं। मैं तीसरे एमवीवीएम समस्या को लागू करने के लिए तीसरे को थोड़ा जटिल करता हूं, अर्थात् ListBox.SelectedItems को ViewModel को बांधने का कार्य। यह एक अलग विषय है, जो मेरी राय में एक अलग लेख के योग्य है। मज़े के लिए, आप नीचे दिए गए स्पॉइलर मार्कअप के नीचे देख सकते हैं।

मार्कअप पेज 3

 <Page x:Class="Pages.Page3" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:tkx="http://schemas.xceed.com/wpf/xaml/toolkit" mc:Ignorable="d" d:DesignHeight="400" d:DesignWidth="400"> <Grid> <tkx:ChildWindow WindowState="Open" Caption="My Dialog" IsModal="True" WindowStartupLocation="Center"> <Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition /> </Grid.RowDefinitions> <TextBlock Text="{Binding Page3Text, FallbackValue='No Data'}" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="24" FontWeight="Bold"/> <StackPanel Grid.Row="1"> <TextBlock Text="Category:" Margin="5"/> <ComboBox Text="Select..." Margin="5"> <ComboBoxItem Content="Category 1"/> <ComboBoxItem Content="Category 2"/> <ComboBoxItem Content="Category 3"/> </ComboBox> <TextBlock Text="Items:" Margin="5 10 5 5"/> <ListBox Margin="5" SelectionMode="Multiple"> <ListBoxItem Content="Item 1"/> <ListBoxItem Content="Item 2"/> <ListBoxItem Content="Item 3"/> <ListBoxItem Content="Item 4"/> <ListBoxItem Content="Item 5"/> <ListBoxItem Content="Item 6"/> <ListBoxItem Content="Item 7"/> <ListBoxItem Content="Item 8"/> </ListBox> </StackPanel> </Grid> </tkx:ChildWindow> </Grid> </Page>

इस पृष्ठ पर मैंने एक निश्चित श्रेणी से तत्वों के चयन के साथ एक सरल संवाद पोस्ट किया। यह वास्तविकता के करीब एक उदाहरण है। ऊपर मुख्य विंडो के स्क्रीनशॉट में संवाद का प्रकार दिखाया गया था। ध्यान दें, टेक्स्ट ब्लॉक डायलॉग बॉक्स में झूठ लगता है, लेकिन यह बिना किसी ट्रिक के सीधे पेज के DataContext से जुड़ जाता है। यह WPF टूलकिट विस्तारित से चाइल्डविंडो की योग्यता है। यह नियंत्रण वास्तव में केवल संवाद बॉक्स के व्यवहार का अनुकरण करता है और XAML मार्कअप में अपने माता-पिता का प्रत्यक्ष वंशज है। इस प्रकार, DataContext चाइल्डविंडो में ग्रिड से विरासत में मिला है जिसमें मैंने इसे डाला है।
सूची बॉक्स में कई चयन को बांधने की समस्या के बारे में संक्षेप में। ViewModel की सूची में चयनित सूचीबॉक्स तत्वों पर लौटने के लिए, मैं सीधे बाइंडरों का उपयोग नहीं कर सकता, क्योंकि संपत्ति ListBox.SelectedItems बाध्यकारी का समर्थन नहीं करता है। इस समस्या को हल करने के लिए, आप ListBox को अपने नियंत्रण से इनहेरिट कर सकते हैं जिसमें DependencyProperty को जोड़ना है। हालांकि, एमवीवीएम के संदर्भ में अधिक लचीला दृष्टिकोण है, जो मैं एक अलग लेख के बारे में लिखने जा रहा हूं, यदि आप रुचि रखते हैं।

IoC (प्रबंधन का उलटा)

दुर्भाग्य से, मैं इस लेख में इस दृष्टिकोण का विस्तार से वर्णन नहीं कर सकता। वॉल्यूम पहले से ही बड़ा है। लेकिन आप आवश्यक ज्ञान आकर्षित कर सकते हैं, उदाहरण के लिए, हैबर के लेखों से । आप बहुत सारे संसाधन भी गूगल कर सकते हैं। संक्षेप में, "नियंत्रण का व्युत्क्रम" एक विधानसभा से दूसरी विधानसभा में सीधे लिंक को समाप्त करने का एक तरीका है। निर्भरता इंजेक्शन विशेष " कंटेनरों " द्वारा किया जाता है, जो कॉन्फ़िगरेशन फ़ाइलों से पहचानता है कि कौन से विशिष्ट वर्ग और कौन से असेंबलियों को कॉन्फ़िगर में निर्दिष्ट इंटरफ़ेस और अनुभाग नाम के लिए इनिशियलाइज़ करना है। मुझे यह स्वीकार करना चाहिए कि मेरे कोड में IoC पूरी तरह से लागू नहीं है। सच कहूं तो वह उद्देश्य नहीं था। बेशक, मैंने कोड में IoC की अवधारणा को प्रतिबिंबित करने की कोशिश की और यह दिखाने की कोशिश की कि कोड को कम जुड़ा कैसे बनाया जाए।
नीचे कंटेनर इंटरफेस और उनके कार्यान्वयन हैं।

 namespace ViewModels.Interfaces { public interface IViewModelsResolver { INotifyPropertyChanged GetViewModelInstance(string alias); } } namespace Navigator.Navigation.Interfaces { public interface IPageResolver { Page GetPageInstance(string alias); } }

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

परीक्षण कंटेनर कार्यान्वयन

 namespace Navigator.Navigation { public class PagesResolver : IPageResolver { private readonly Dictionary<string, Func<Page>> _pagesResolvers = new Dictionary<string, Func<Page>>(); public PagesResolver() { _pagesResolvers.Add(Navigation.Page1Alias, () => new Page1()); _pagesResolvers.Add(Navigation.Page2Alias, () => new Page2()); _pagesResolvers.Add(Navigation.Page3Alias, () => new Page3()); _pagesResolvers.Add(Navigation.NotFoundPageAlias, () => new Page404()); } public Page GetPageInstance(string alias) { if (_pagesResolvers.ContainsKey(alias)) { return _pagesResolvers[alias](); } return _pagesResolvers[Navigation.NotFoundPageAlias](); } } } namespace ViewModels { public class ViewModelsResolver : IViewModelsResolver { private readonly Dictionary<string, Func<INotifyPropertyChanged>> _vmResolvers = new Dictionary<string, Func<INotifyPropertyChanged>>(); public ViewModelsResolver() { _vmResolvers.Add(MainViewModel.Page1ViewModelAlias, () => new Page1ViewModel()); _vmResolvers.Add(MainViewModel.Page2ViewModelAlias, () => new Page2ViewModel()); _vmResolvers.Add(MainViewModel.Page3ViewModelAlias, () => new Page3ViewModel()); _vmResolvers.Add(MainViewModel.NotFoundPageViewModelAlias, () => new Page404ViewModel()); } public INotifyPropertyChanged GetViewModelInstance(string alias) { if (_vmResolvers.ContainsKey(alias)) { return _vmResolvers[alias](); } return _vmResolvers[MainViewModel.NotFoundPageViewModelAlias](); } } }

ये सिर्फ कंटेनर की "गुड़िया" हैं जिन्हें कुछ के साथ प्रबंधित करने की आवश्यकता है, उदाहरण के लिए, एकता पुस्तकालय से। इंटरफेस के रूप में IUnityContainer जैसी किसी चीज़ का उपयोग करना बेहतर होगा, लेकिन मैं अतिरिक्त संदर्भ के साथ समाधानों को बोझ नहीं बनाना चाहता था और मेरे नेविगेटर कार्यान्वयन की धारणा को जटिल करता था। इसके अलावा, आप यूनिटी के बजाय किसी अन्य IoC लाइब्रेरी को प्राथमिकता दे सकते हैं।

आगे पढ़ रहे हैं

विकिपीडिया पर सिंगलटन के बारे में
हैब्रहाब पर सिंगलटन के बारे में
विकिपीडिया पर MVVM पैटर्न के बारे में
हबराब्र पर एमवीवीएम पैटर्न के बारे में