प्रिज्म डेवलपर की गाइड - भाग 7.1, यूजर इंटरफेस डिजाइन सिफारिशें

सामग्री की तालिका

1. परिचय
2. प्रारम्भिक प्रिज्म अनुप्रयोग
3. घटकों के बीच निर्भरता का प्रबंधन
4. मॉड्यूलर अनुप्रयोग विकास
5. एमवीवीएम पैटर्न को लागू करना
6. उन्नत MVVM परिदृश्य
7. उपयोगकर्ता इंटरफ़ेस निर्माण
   
   1. उपयोगकर्ता इंटरफ़ेस दिशानिर्देश
8. नेविगेशन
   1. दृश्य-आधारित नेविगेशन
9. शिथिल युग्मित घटकों के बीच पारस्परिक क्रिया

उपयोगकर्ता इंटरफ़ेस दिशानिर्देश

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

यूआई विकास

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

कंटेनर संरचना

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

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

तत्व डिजाइन के दौरान दिखाई नहीं दे सकते हैं, इसलिए, यह निर्धारित करना कि वे किस आकार का होना चाहिए और आवेदन के सामान्य स्वरूप के अनुरूप कैसे होंगे, कुछ कठिनाइयों को प्रस्तुत करता है। अपने कंटेनरों की रचना करते समय निम्नलिखित बिंदुओं पर विचार करें:

• क्या अधिकतम सामग्री आकार पर कोई प्रतिबंध है? यदि मौजूद है, तो स्क्रॉलिंग का समर्थन करने वाले कंटेनरों का उपयोग करने पर विचार करें।
• Expander और ScrollViewer संयोजन का उपयोग उन स्थितियों के लिए करें जहां बड़ी मात्रा में गतिशील सामग्री को एक सीमित स्थान पर रखने की आवश्यकता होती है।
• यह सुनिश्चित करने के लिए ध्यान दें कि जब एप्लिकेशन विंडो किसी भी विंडो आकार में आकर्षक लगेगी, यह सुनिश्चित करने के लिए कि सामग्री विंडो का आकार कैसा होगा, तो उसका आकार कैसा होगा।

एक्सप्रेशन ब्लेंड में स्टॉक ट्रेडर आरआई की मुख्य विंडो।


स्टार्टअप के बाद स्टॉक ट्रेडर आरआई की मुख्य विंडो।

विकास के दौरान समग्र अनुप्रयोग का दृश्य

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

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

अंकन

एक समग्र अनुप्रयोग के लेआउट को डिजाइन करते समय निम्नलिखित बिंदुओं पर विचार करें:

• शेल एप्लिकेशन के मूल लेआउट को परिभाषित करता है। प्रत्येक लेआउट क्षेत्र एक क्षेत्र है, और एक खाली कंटेनर होना चाहिए। डिज़ाइन के दौरान सामग्री को क्षेत्रों के अंदर न रखें, इसे स्टार्टअप पर लोड किया जाएगा।
• शेल में पृष्ठभूमि और हेडर होना चाहिए। इसे ASP.NET में एक मास्टर पेज के रूप में सोचें।
• इस क्षेत्र के लिए कंटेनर के रूप में काम करने वाले नियंत्रण उस दृश्य से अलग होते हैं जो उनके पास होते हैं। इसलिए, आपको नियंत्रणों को संशोधित किए बिना दृश्य का आकार बदलने में सक्षम होना चाहिए, और दृश्य को संशोधित किए बिना नियंत्रणों का आकार बदलना होगा। दृश्य का आकार सेट करते समय आपको निम्नलिखित बिंदुओं पर विचार करना चाहिए:
  
  • यदि दृश्य कई क्षेत्रों में उपयोग किया जाएगा, या आप सुनिश्चित नहीं हैं कि इसका उपयोग कहाँ किया जाएगा, तो इसे गतिशील ऊँचाई और चौड़ाई के साथ डिज़ाइन करें।
  • यदि दृश्य में निश्चित आकार हैं, तो शेल के क्षेत्रों में गतिशील आकार होना चाहिए।
  • यदि शेल के क्षेत्रों में निश्चित आकार हैं, तो विचारों में गतिशील आकार होना चाहिए।
  • दृश्यों को एक निश्चित ऊंचाई और गतिशील चौड़ाई की आवश्यकता हो सकती है। इस दृष्टिकोण के एक उदाहरण के रूप में, स्टॉक ट्रेडर आरआई के पास साइडबार पर स्थित एक PositionPieChart दृश्य है।
  • अन्य दृश्यों में गतिशील ऊंचाई और चौड़ाई हो सकती है। उदाहरण के लिए, स्टॉक ट्रेडर आरआई में साइडबार में NewsReader । इसकी ऊंचाई इसके शीर्षक की लंबाई पर निर्भर करती है, और चौड़ाई हमेशा क्षेत्र के आकार के अनुरूप होनी चाहिए। वही नियम स्थितियुमस्मेरिएव पर लागू होते हैं, जहाँ तालिका की चौड़ाई स्क्रीन के आकार और तालिका में पंक्तियों की संख्या के अनुरूप होनी चाहिए।
  
  
• दृश्यों में मूल रूप से एक पारदर्शी पृष्ठभूमि होनी चाहिए, जो शेल को अपनी पृष्ठभूमि प्रदान करने की अनुमति देती है।
• रंग, ब्रश और फोंट असाइन करने के लिए हमेशा नामित संसाधनों का उपयोग करें, बजाय उन्हें सीधे तत्व गुणों के लिए असाइन करने के लिए। यह अनुप्रयोग समर्थन को बहुत सरल करेगा। इसके अलावा, यह रनटाइम पर संसाधन शब्दकोशों में गतिशील परिवर्तनों के प्रदर्शन की अनुमति दे सकता है।

एनिमेशन

निम्नलिखित बिंदुओं पर विचार करें यदि आप शेल में या विचारों में एनिमेशन का उपयोग करते हैं:

• आप शेल के लेआउट को चेतन कर सकते हैं, लेकिन आपको इसकी सामग्री और विचारों को व्यक्तिगत रूप से चेतन करने की आवश्यकता होगी।
• प्रत्येक दृश्य को व्यक्तिगत रूप से डिज़ाइन और चेतन करें।
• यह इंगित करने के लिए कि दृश्य तत्व जोड़ा गया है या दृश्य से हटा दिया गया है, नरम और विनीत एनिमेशन का उपयोग करें। यह आपके एप्लिकेशन को एक चमक देगा।

अभिव्यक्ति ब्लेंड, राज्यों और घटनाओं के आधार पर एनिमेशन और बदलाव बनाने और संपादित करने के लिए व्यवहार, क्षीणन कार्यों और समृद्ध अवसरों का एक समृद्ध सेट प्रदान करता है। अधिक जानकारी के लिए, MSDN पर "VisualStateManager Class" लेख देखें।

रनटाइम अनुकूलन

प्रदर्शन को अनुकूलित करने के लिए निम्नलिखित बिंदुओं पर विचार करें:

• App.xaml फ़ाइल में या शैली को दोहराव से बचाने के लिए App.xaml में कोई साझा संसाधन रखें।
• सिल्वरलाइट में, बाकी एप्लिकेशन के अलावा टेक्स्ट स्टाइल के लिए नॉन-सिस्टम फोंट का उपयोग करने से बचें, जैसे कि हेडिंग। इस स्थिति में, पाठ को पथ में परिवर्तित करने या किसी एप्लिकेशन में फ़ॉन्ट एम्बेड करने पर विचार करें। किसी एप्लिकेशन में फ़ॉन्ट को एम्बेड करना उसके आकार को महत्वपूर्ण रूप से प्रभावित कर सकता है, क्योंकि कुछ फ़ॉन्ट फ़ाइलें अपेक्षाकृत बड़ी हैं। डाउनलोड की गई .xap फ़ाइल के आकार को कम करने के लिए, एक्सप्रेशन ब्लेंड आपको वर्णों के केवल सबसेट को लोड करने की अनुमति देता है, न कि पूरे फ़ॉन्ट को।

अधिक जानकारी के लिए, "सिल्वरलाइट में कस्टम फ़ॉन्ट्स का उपयोग करना" देखें।

डिजाइन समय अनुकूलन

किसी एप्लिकेशन के विज़ुअल डिज़ाइन के दौरान आने वाली कुछ समस्याओं के लिए अनुशंसाएँ और समाधान निम्नलिखित हैं।

XAML संसाधनों के बहुत से महान समाधान

कई XAML संसाधनों के साथ एक बड़े समाधान में जो इसका हिस्सा हैं, दृश्य संपादक का लोडिंग समय बहुत बढ़ सकता है। ऐसा इसलिए होता है क्योंकि दृश्य संपादक को सभी एम्बेडेड संसाधनों को डाउनलोड और पार्स करना होगा। इससे निपटने का एक तरीका यह है कि सभी XAML संसाधनों को एक अलग परियोजना में स्थानांतरित किया जाए, इस परियोजना को संकलित किया जाए, और फिर मूल परियोजना से परिणामी DLL के लिए एक लिंक बनाया जाए। चूंकि अब सभी संसाधन बाइनरी असेंबली में हैं, इसलिए डिजाइनर को उन्हें अपने दम पर अलग करने की आवश्यकता नहीं है, जो डिजाइन के दौरान उत्पादकता को सकारात्मक रूप से प्रभावित करता है। XAML संसाधनों को किसी अन्य प्रोजेक्ट में ले जाते समय, आप अपने संसाधनों के लिए ComponentResourceKeys का उपयोग करने पर विचार कर सकते हैं। अधिक जानकारी के लिए, MSDN पर "ComponentResourceKey Markup Extension" देखें।

XAML संसाधन

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

दृश्य संपादक और बनाता है

संसाधनों के लिए एक अलग असेंबली का उपयोग करने का नकारात्मक पहलू यह है कि अभिव्यक्ति ब्लेंड और विज़ुअल स्टूडियो 2010 में संपत्ति संपादक ऐसी विधानसभाओं में स्थित संसाधनों को प्रदर्शित नहीं करता है। यह निम्नानुसार है कि आपको अन्य विधानसभाओं में स्थित संसाधनों के नामों को मैन्युअल रूप से लिखना होगा।

सिल्वरलाइट डिजाइन-टाइम App.xaml संसाधन

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

सैटेलाइट असेंबलियों के लिए सिल्वरलाइट प्रोजेक्ट टेम्प्लेट का विकल्प तैनात करते समय एक लाभ प्रदान करता है: विधानसभा को संकलन के लिए एक .xap फ़ाइल में पैक किया जाएगा। हालांकि, एक साइड इफेक्ट यह है कि विज़ुअल डिज़ाइनर, अगर एक समाधान में कई सिल्वरलाइट प्रोजेक्ट हैं, तो केवल सक्रिय प्रोजेक्ट की App.xaml फ़ाइल से संसाधनों का उपयोग करता है।

एक्सप्रेशन ब्लेंड 4 इस समस्या का समाधान प्रदान करता है। जब वह इस तरह की समस्या की पहचान करता है, तो वह एक संवाद प्रदर्शित करता है जहां वह आवश्यक संसाधन पुस्तकालय का चयन करने का सुझाव देता है जिसका उपयोग पूरे आवेदन के दौरान किया जाएगा। दृश्य स्टूडियो 2010 में इस तरह के एक समारोह नहीं है, क्रमशः, उपग्रह असेंबलियों में दृश्य संपादन के लिए एक ही समर्थन नहीं होगा, जब तक कि आप सभी एप्लिकेशन-स्तरीय संसाधनों को एक अलग विधानसभा में नहीं डालते। यदि आपने इस दृष्टिकोण को चुना है, तो आवेदन को तैनात करने से पहले उपग्रह विधानसभा परियोजनाओं से इन संसाधनों को हटाना सुनिश्चित करें।

डिजाइन के अनुकूल दृश्य गाइड

निम्नलिखित बिंदु डिजाइन के अनुकूल विचारों की विशेषताएं हैं (जिन्हें मिश्रण योग्य या उपकरण-सक्षम के रूप में भी जाना जाता है):

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

संपादन के दौरान कई बार निम्न ऑपरेशन किए जाते हैं। कस्टम कोड जो डिजाइनर के अनुकूल नहीं है, उनके निष्पादन में हस्तक्षेप कर सकता है, जिससे डिजाइनर या प्रोग्रामर की उत्पादकता कम हो सकती है।

• डिजाइन की सतह क्रियाएं:
  
  • ऑब्जेक्ट बनाएँ
  • लोड हो रहा है वस्तुओं
  • संपत्ति मान सेट करना
  • डिज़ाइन सरफेस इवेंट हैंडलिंग
  • रूट तत्व के रूप में नियंत्रण का उपयोग करना
  • एक नियंत्रण दूसरे के अंदर डालना
  • XAML फ़ाइल खोलना, बंद करना और पुनः लोड करना
  • परियोजना का पुन: स्थापन
  • डिजाइनर रीलोड
  
  
• बाध्यकारी अभिव्यक्ति बिल्डर के कार्य:
  
  • DataContext डिटेक्शन
  • उपलब्ध डेटा स्रोतों की सूची बनाना
  • डेटा स्रोत प्रकार गुणों की गणना
  
  
• डिजाइन समय के नमूने डेटा के कार्य:
  
  • नमूना डेटा को सही ढंग से प्रदर्शित करने के लिए डिज़ाइन की सतह पर नियंत्रण का उपयोग करना
  
  

डिजाइन के दौरान निष्पादन के लिए कोड बनाना

एक डिजाइनर का उपयोग करने की सुविधा के लिए, विज़ुअल स्टूडियो और एक्सप्रेशन ब्लेंड ऑब्जेक्ट बनाते हैं और डिज़ाइन के दौरान कोड निष्पादित करते हैं। हालाँकि, कोड के कारण होने वाले अशक्त संदर्भ अपवाद वस्तुओं को एक्सेस करने का प्रयास करते हैं इससे पहले कि वे डिज़ाइन किए जाने के दौरान लोडिंग त्रुटियों और अनावश्यक अपवादों की एक बड़ी संख्या का कारण बन सकते हैं।

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

अपने कोड में इससे बचें	दृश्य स्टूडियो 2010	ब्लेंड ४
डिजाइन के दौरान कई धागे चल रहे हैं। उदाहरण के लिए, निर्माण में, या Loaded घटना में Timer बनाना और शुरू करना।
उन नियंत्रणों का उपयोग करना जो डिजाइन के दौरान स्टैक ओवरफ्लो का कारण बन सकते हैं, या जो स्वयं को पुन: लोड करते हैं।
कनवर्टर, या डेटा टेम्पलेट चयनकर्ता में एक शून्य संदर्भ अपवाद को फेंकना।
एक शून्य संदर्भ अपवाद, या कंस्ट्रक्टर में किसी अन्य अपवाद को फेंकना। इसके कारण हो सकता है: कोड का उपयोग करना, जो डिज़ाइन के दौरान, डेटाबेस से या नेटवर्क के माध्यम से डेटा को पुनः प्राप्त करने के लिए व्यापारिक परत या एप्लिकेशन डेटा लेयर को कॉल करता है। बूटलोडर या कंटेनर इनिशियलाइज़ेशन कोड को चलाने से पहले कंटेनर का उपयोग करते समय निर्भरता को हल करने का प्रयास।
नियंत्रण के Loaded घटना के अंदर एक शून्य संदर्भ अपवाद, या किसी अन्य अपवाद को फेंकना। यह तब हो सकता है जब आप नियंत्रण की स्थिति के बारे में एक धारणा बनाते हैं, जो रनटाइम पर सही हो सकती है लेकिन डिज़ाइन समय पर निष्पादित नहीं की जाती है।
डिज़ाइन के दौरान Application.Current या Application.Current ऑब्जेक्ट तक पहुँचने का प्रयास।
WPF UserControls में StaticResource का उपयोग करना।
बहुत बड़ी परियोजनाओं का निर्माण।

डिजाइन के दौरान कोड मुद्दों को संभालना

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

जब आपका एप्लिकेशन लॉन्च के बाद चलना शुरू होता है, तो App.xaml.cs में कोड App.xaml.cs । यदि कोई कोड है जिस पर आपका आवेदन निर्भर करता है, तो इसे डिजाइन के दौरान निष्पादित नहीं किया जाएगा। यदि आप उम्मीद नहीं करते हैं, तो निश्चित रूप से अवांछित अपवाद उत्पन्न होंगे। इसे ठीक करने के लिए:

• कभी भी यह न समझें कि डिजाइन के दौरान कोई ऑब्जेक्ट बनाया जाएगा। कोड में जिसे डिजाइन के दौरान निष्पादित किया जा सकता है, हमेशा ऑब्जेक्ट के साथ काम करने से पहले null जांच करें।
• यदि आपका कोड Application ऑब्जेक्ट या Application.Current ऑब्जेक्ट के साथ काम करता है, तो इससे पहले कि उन्हें null लिए जांचें।
• यदि आपके निर्माता में कोड, या Loaded घटना में, एक डेटाबेस या नेटवर्क सेवा का उपयोग करता है, तो निम्न विकल्पों पर विचार करें:
  
  • कोड को कॉल करने से पहले, जाँच लें कि क्या यह निम्नलिखित विधि का संदर्भ देकर डिज़ाइनर में निष्पादित किया गया है:
    
    • WPF : DesignerProperties.GetIsInDesignMode
    • सिल्वरलाइट : DesignerProperties.IsInDesignTool
    
    
  • कोड को सीधे कंस्ट्रक्टर में, या Loaded ईवेंट हैंडलर में चलाने के बजाय, इसे इंटरफ़ेस के माध्यम से विधि कॉल के पीछे अमूर्त करें, जिसके बाद आप रनटाइम, डिज़ाइन, और परीक्षणों में विभिन्न कार्यान्वयन का उपयोग करने के लिए कई तकनीकों में से एक को लागू कर सकते हैं।
  
  

यह निर्धारित करना कि कोड डिजाइन के दौरान निष्पादित किया जाता है

एक्सप्रेशन ब्लेंड और विज़ुअल स्टूडियो दोनों डिज़ाइनर पैनल में प्रदर्शित रूट ऑब्जेक्ट लेआउट का उपयोग करते हैं। यह आवश्यक कार्यों के साथ डिजाइनर प्रदान करने के लिए आवश्यक है। चूंकि रूट ऑब्जेक्ट नकली है, इसके निर्माता और Loaded ईवेंट को डिज़ाइन के दौरान नहीं कहा जाता है। हालाँकि, मंच पर शेष नियंत्रण सामान्य रूप से निर्मित होते हैं, और उनकी Loaded घटना को रन टाइम पर ही Loaded जाता है।

निम्नलिखित दृष्टांत में, Windows रूट एलिमेंट के कंस्ट्रक्टर और उसके Loaded इवेंट को नहीं कहा जाता है, और चाइल्ड एलिमेंट को नहीं कहा जाता है।



यह अवधारणा विशेष रूप से महत्वपूर्ण है जब समग्र अनुप्रयोगों का निर्माण किया जाता है जो गतिशील रूप से रनटाइम पर बनाए जाते हैं।

आवेदन में अधिकांश विचार स्वतंत्र रूप से बनाए गए हैं। इस वजह से, वे आमतौर पर डिजाइनर में मूल वस्तुएं हैं, क्रमशः, उनके निर्माता और Loaded घटनाओं को कभी नहीं कहा जाता है।

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

डिजाइन समय गुण

" d: " उपसर्ग के साथ अंतर्निहित डिज़ाइन-टाइम गुण डिज़ाइन के दौरान उत्पादकता बढ़ाने के लिए एक आसान तरीका प्रदान करते हैं।

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

निम्न अनुभागों का वर्णन है कि कैसे उपयोग करें d:DataContext और d:DesignInstance मार्कअप d:DesignInstance ।

पिछले पैराग्राफ में " d: " नामस्थान का एक उपनाम है जिसमें डिज़ाइन-टाइम टूल स्थित हैं। निम्नलिखित लेख " d: " गुणों और मार्कअप एक्सटेंशन के बारे में अधिक विस्तार से वर्णन करते हैं:

• "WPF डिजाइनर में डिज़ाइन-टाइम विशेषताएँ"
• "सिल्वरलाइट डिज़ाइनर में डिज़ाइन-टाइम विशेषताएँ"

" d: " गुण और मार्कअप एक्सटेंशन नहीं बनाए जा सकते हैं, या उपयोगकर्ता कोड में उपयोग किए जा सकते हैं, वे केवल एक्सएएमएल में लागू किए जा सकते हैं। वे आपके एप्लिकेशन में भी संकलित नहीं करते हैं, वे केवल विज़ुअल स्टूडियो और एक्सप्रेशन ब्लेंड में टूल द्वारा उपयोग किए जाते हैं।

संपत्ति d: DataContext

d:DataContext नियंत्रण और उसके वंशज के लिए रनटाइम डेटा संदर्भ सेट करता है। d:DataContext निर्दिष्ट करते समय d:DataContext आपको रन टाइम के दौरान DataContext डेटा संदर्भ के लिए हमेशा एक ही प्रकार का डेटा प्रदान करना चाहिए।

यदि कोई DataContext और d:DataContext दोनों नियंत्रण के लिए निर्दिष्ट d:DataContext , तो डिज़ाइन उपकरण d:DataContext चयन करेंगे।

डी मार्कअप एक्सटेंशन: DesignInstance

यदि आपको नहीं पता है कि मार्कअप एक्सटेंशन क्या हैं, तो मैं आपको एमएसडीएन लेख "मार्कअप एक्सटेंशन और डब्ल्यूपीएफ एक्सएएमएल" पढ़ने की सलाह देता हूं।

d:DesignInstance डिजाइन के दौरान डेटा संदर्भ के रूप में उपयोग किए जाने वाले प्रकार की एक वस्तु बनाता है और लौटाता है। इस प्रकार का ऑब्जेक्ट बनाने की क्षमता के साथ नहीं होना चाहिए। निम्नलिखित पैराग्राफ d:DesignInstance के गुणों की व्याख्या करते हैं d:DesignInstance :

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

डी के लिए विशिष्ट उपयोग के मामले : DataContext

निम्न कोड उदाहरण प्रस्तुति मॉडल के साथ विचारों को जोड़ने के लिए एक दोहराव पैटर्न दिखाते हैं।

पर्सन PersonViewModel में रनटाइम पर हल किए गए PersonViewModel पर निर्भरता है। हालांकि उदाहरण में प्रस्तुत मॉडल को जानबूझकर सरलीकृत किया जाता है, वास्तविक अनुप्रयोगों में इसकी निर्भरता आमतौर पर कंस्ट्रक्टर में इंजेक्ट की जाएगी।

निर्मित होने पर PersonView, इसकी निर्भरता PersonViewModelकंटेनर के माध्यम से बनाई और हल की जाएगी।

नोट।
यदि प्रस्तुति मॉडल में कोई निर्भरता नहीं है, तो इसे पूरी तरह से XAML में बनाया जा सकता है। इस स्थापना में DataContext, और d:DataContextजरूरी नहीं है।

PersonViewModel.cs

 [Export] public class PersonViewModel { public String FirstName { get; set; } public String LasName { get; set; } } 

PersonView.xaml.cs

 [Export] public partial class PersonView : UserControl { public PersonView() { InitializeComponent(); } [Import] public PersonViewModel ViewModel { get { return this.DataContext as PersonViewModel; } set { this.DataContext = value; } } } 

प्रस्तुति और प्रस्तुति मॉडल को जोड़ने के लिए यह एक अच्छा खाका है। हालांकि, यह अंधेरे में एक विचार छोड़ देता है कि डिजाइन के दौरान इसे किस डेटा संदर्भ का उपयोग करना चाहिए।

अगले XAML में, आप उस d:DesignInstanceतत्व पर उपयोग किए गए मार्कअप एक्सटेंशन को देख सकते हैं जो Gridउस छद्म उदाहरण PersonViewModelको लौटाता है जिसमें संपत्ति सेट की गई है d:DataContext। नतीजतन, बच्चों में Gridमूल्य का उत्तराधिकार होगा d:DataContext, जो आपको डेटा संदर्भ में गुणों और प्रकारों की समीक्षा करने के लिए डिज़ाइन टूल का उपयोग करने की अनुमति देता है, जो डिजाइनर और प्रोग्रामर के काम को बहुत सुविधाजनक बनाता है।

PersonView.xaml

 <UserControl xmlns:local="clr-namespace:WpfApplication1" x:Class="WpfApplication1.PersonView" 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" mc:Ignorable="d" d:DesignHeight="300" d:DesignWidth="300"> <Border BorderBrush="LightGray" BorderThickness="1" CornerRadius="10" Padding="10"> <Grid d:DataContext="{d:DesignInstance local:PersonViewModel}"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="Auto" /> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="100" /> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <Label Grid.Column="0" Grid.Row="0" Content="First Name" /> <Label Grid.Column="0" Grid.Row="1" Content="Las Name" /> <TextBox Grid.Column="1" Grid.Row="0" Width="150" MaxLength="50" HorizontalAlignment="Left" VerticalAlignment="Top" Text="{Binding Path=FirstName, Mode=TwoWay}" /> <TextBox Grid.Column="1" Grid.Row="1" Width="150" MaxLength="50" HorizontalAlignment="Left" VerticalAlignment="Top" Text="{Binding Path=LasName, Mode=TwoWay}" /> </Grid> </Border> </UserControl> 

: ViewModel Locator .
, . , , , . DataContext . , , .

, d:DataContext – d:DesignInstance , , d:DesignInstance।

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

डिजाइन समय नमूना गाइड

WPF और सिल्वरलाइट डिज़ाइन टीम ने एक गहन लेख प्रकाशित किया है जो WPF और सिल्वरलाइट परियोजनाओं में नमूना डेटा के उपयोग का वर्णन करता है। MSDN पर एक लेख उपलब्ध है: "WPF और सिल्वरलाइट डिजाइनर में नमूना डेटा । "

नमूना डेटा ( डिज़ाइन-टाइम नमूना डेटा ) का उपयोग करना

विज़ुअल डिज़ाइन टूल जैसे एक्सप्रेशन ब्लेंड या विज़ुअल स्टूडियो का उपयोग करते समय नमूना डेटा विशेष रूप से महत्वपूर्ण हो जाता है। दृश्यों को डेटा और छवियों से भरा जा सकता है, जो डिजाइनर के काम को बहुत सरल करता है और उसे अधिक उत्पादक बनाता है।

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

स स स स स स

आप निम्न स्रोतों से नमूना डेटा प्राप्त कर सकते हैं:

• एक्सप्रेशन ब्लेंड XML नमूना डेटा
• एक्सप्रेशन ब्लेंड 4 और विजुअल स्टूडियो 2010 एक्सएएमएल नमूना डेटा
• XAML संसाधन
• कोड

इन स्रोतों से डेटा प्राप्त करने पर नीचे चर्चा की गई है।

एक्सप्रेशन ब्लेंड XML नमूना डेटा

एक्सप्रेशन ब्लेंड आपको XML स्कीमा बनाने और डेटा के साथ संबंधित XML फ़ाइल को पॉप्युलेट करने में सक्षम बनाता है। यह समाधान में किसी भी बाहरी परियोजनाओं को जोड़ने के बिना किया जाता है।

इस प्रकार के नमूना डेटा का उद्देश्य यह है कि डिजाइनर आवश्यक कक्षाओं को लिखने के लिए प्रोग्रामर की प्रतीक्षा किए बिना परियोजना पर काम करना शुरू कर सकता है।

हालाँकि अधिकांश नमूना डेटा एक्सप्रेशन ब्लेंड और विज़ुअल स्टूडियो 2010 डिज़ाइनर दोनों में उपलब्ध है, एक्सएमएल सैंपल डेटा एक्सप्रेशन ब्लेंड की एक विशेषता है और विज़ुअल स्टूडियो 2010 में दिखाई नहीं देता है।

नोट।
नमूना XML डेटा फ़ाइल को संकलित या विधानसभा में नहीं जोड़ा गया है। हालाँकि, XML स्कीमा को अंतिम असेंबली में संकलित किया गया है।

एक्सप्रेशन ब्लेंड 4 और विजुअल स्टूडियो 2010 एक्सएएमएल सैंपल डेटा

एक्सप्रेशन ब्लेंड 4 और विज़ुअल स्टूडियो 2010 के साथ शुरू करते हुए, एक मार्कअप एक्सटेंशन जोड़ा गया d:DesignDataहै जो आपको डिज़ाइन के दौरान नमूना डेटा लोड करने की अनुमति देता है।

नमूना डेटा के साथ एक XAML फ़ाइल में मार्कअप होता है जिसमें एक या कई प्रकार के उदाहरण बनाए जाते हैं, जिसके बाद कुछ डेटा को उनके गुणों को सौंपा जाता है।

इसमें d:DesignDataएक संपत्ति है Sourceजो परियोजना में स्थित एक XAML नमूना डेटा फ़ाइल पर URI लेता है। मार्कअप एक्सटेंशन d:DesignDataइस फ़ाइल को डाउनलोड करता है, इसे पार्स करता है, और ऑब्जेक्ट ग्राफ देता है। इसका उपयोग किसी संपत्ति d:DataContext, संपत्ति CollectionViewSource d:DesignSourceया संपत्ति द्वारा किया जा सकता है DomainDataSource d:DesignData।

एक्सटेंशन द्वारा हल की गई समस्याओं में से एकd:DesignData, यह है कि यह कस्टम प्रकार के लिए नमूना डेटा बना सकता है जिसे बनाया नहीं जा सकता है। उदाहरण के लिए, WCF RIA एप्लिकेशन में, सेवा निकाय ऑब्जेक्ट कोड में नहीं बनाए जा सकते हैं। इसके अतिरिक्त, डेवलपर्स के अपने गैर-निर्मित प्रकार हो सकते हैं, जिसके लिए आप अभी भी नमूना डेटा बनाना चाहते थे।

आप नीचे दिखाए गए तरीके से d:DesignDataअपने डेटा का नमूना सॉल्यूशन एक्सप्लोरर में डेटा फ़ाइल की बिल्ड एक्शन प्रॉपर्टी को सेट करके संसाधित कर सकते हैं :

• बिल्ड एक्शन = डिजाइनडेटा - छद्म प्रारूप बनाए जाएंगे
• बिल्ड एक्शन = DesignDataWithDesignTimeCreatableTypes - वास्तविक प्रकार बनाए जाएंगे

जब नमूना डेटा बनाने के लिए एक्सप्रेशन ब्लेंड का उपयोग किया जाता है, तो यह XAML फ़ाइल बनाता है जिसमें पहले से डिज़ाइनडैटा में निर्मित बिल्ड एक्शन होता है । यदि आपको वास्तविक प्रकार की आवश्यकता है, तो Visual Studio में समाधान खोलें और डेटा फ़ाइल के लिए Build Action को DesignDataWithDesignTimeCreatableTypes में बदलें ।

नोट।
, Custom Tool . . , Expression Blend .

Visual Studio 2010, , . , Build Action Custom Tool .

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

एक्सप्रेशन ब्लेंड 4 में सैंपल्ड डेटा को परिभाषित करना, सैंपल्ड डेटा


बनाने के बाद, यह डेटा पैनल में दिखाई देगा, जैसा कि नीचे दिखाया गया है।

डेटा पैनल।


उसके बाद, आप उन्हें दृश्य के मूल तत्व पर खींच सकते हैं, जैसे UserControlकि यह ठीक से स्थापित करेगा d:DataContext । आप नमूना डेटा के संग्रह को भी खींच सकते हैं ItemsControl, जिसके बाद ब्लेंड उस डेटा के लिए एक बंधन बनाएगा।

नोट।
अंतिम XAML डेटा को संकलित या अंतिम विधानसभा में शामिल नहीं किया गया है।

XAML संसाधन

आप XAML में एक संसाधन बना सकते हैं, जहाँ वांछित प्रकार बनाया जाता है, और फिर इसे DataContextया सूची में बाँध दिया जाता है ।

इस तकनीक का उपयोग डेटा टेम्पलेट को संपादित करने के लिए उपयोग किए जाने वाले एक-बार डेटा को जल्दी से करने के लिए किया जा सकता है।

कोड

यदि आप कोड में नमूना डेटा बनाना पसंद करते हैं, तो आप एक वर्ग लिख सकते हैं जिसमें गुण और तरीके हैं जो नमूना डेटा लौटाते हैं। उदाहरण के लिए, आप एक ऐसा वर्ग लिख सकते हैं, Customersजिसमें एक मानक पैरामीटर रहित निर्माता Customerआवश्यक डेटा से भरे वर्ग के उदाहरणों के साथ खुद को भरता है ।

इस तरह के डेटा का उपभोग करने का एक तरीका d:DataContext — d:DesignInstanceसंपत्ति d:DesignInstance.IsDesignTimeCreatableको सेट करके एक बंडल का उपयोग करना है true, ताकि कोड डिजाइन के दौरान निष्पादित हो। यदि यह संपत्ति सेट नहीं है, तो एक छद्म प्रकार बनाया जाएगा, और केवल प्रकार डेटा डिजाइन के दौरान उपलब्ध होगा।

निम्नलिखित XAML एक वर्ग का एक उदाहरण बनाने Customersऔर इसे स्थापित करने के रूप में प्रदर्शित करता है d:DataContext। के सहायकGridनियंत्रण तब वर्ग द्वारा प्रदान किए गए नमूना डेटा का उपयोग कर सकते हैं Customers।

 <Grid d:DataContext="{d:DesignInstance local:Customers, IsDesignTimeCreatable=True}"> 

उपयोगकर्ता इंटरफ़ेस लेआउट बनाते समय मुख्य निर्णय

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

ये समाधान इस प्रकार हैं:

• एप्लिकेशन प्रवाह को परिभाषित करें और उसके अनुसार क्षेत्रों को सेट करें।
• निर्धारित करें कि किस प्रकार के विचारों का उपयोग किए गए प्रत्येक क्षेत्र में लोड किया जाएगा।
• तय करें कि क्या आप क्षेत्र नेविगेशन एपीआई का उपयोग करेंगे ।
• , (MVVM, presentation model, ).
• .

अतिरिक्त जानकारी

प्रिज्म लाइब्रेरी के विस्तार के बारे में अधिक जानकारी के लिए, " प्रिज़्म का विस्तार " देखें ।

आदेशों के बारे में अधिक जानकारी के लिए, भाग 5 में " कमांड " देखें , " एमवीवीएम पैटर्न को लागू करना ।"

डेटा बाइंडिंग के बारे में अधिक जानकारी के लिए, भाग 5 में " डेटा बाइंडिंग " देखें , " एमवीवीएम पैटर्न लागू करना ।"

नेविगेट करने वाले क्षेत्रों के बारे में अधिक जानकारी के लिए, भाग 8, " नेविगेशन देखें ।"

इस अध्याय में चर्चा की गई गाइड के बारे में अधिक जानकारी के लिए, देखें:

• MSDN पर "निर्भरता गुण अवलोकन":
• http://msdn.microsoft.com/en-us/library/ms752914.aspx .
• Data binding; see:
  • «Data Binding Overview» on MSDN:
    http://msdn.microsoft.com/en-us/library/ms742521.aspx .
  • «Data Binding in WPF» in MSDN Magazine :
    http://msdn.microsoft.com/en-us/magazine/cc163299.aspx .
• «Data Templating Overview» on MSDN:
  http://msdn.microsoft.com/en-us/library/ms742521.aspx .
• «Resources Overview» on MSDN:
  http://msdn.microsoft.com/en-us/library/ms750613.aspx .
• «UserControl Class» on MSDN:
  http://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.aspx .
• «VisualStateManager Class» on MSDN:
  http://msdn.microsoft.com/en-us/library/cc626338(v=VS.95).aspx .
• «Customizing Controls For Windows Presentation Foundation» in MSDN Magazine :
  http://msdn.microsoft.com/en-us/magazine/cc163421.aspx .
• «ComponentResourceKey Markup Extension» MSDN topic:
  http://msdn.microsoft.com/en-us/library/ms753186.aspx .
• «Design-Time Attributes in the WPF Designer» on MSDN:
  http://msdn.microsoft.com/en-us/library/ee839627.aspx .
• «Design-Time Attributes in the Silverlight Designer» on MSDN:
  http://msdn.microsoft.com/en-us/library/ff602277(VS.95).aspx .
• «Markup Extensions and WPF XAML» on MSDN:
  http://msdn.microsoft.com/en-us/library/ms747254.aspx .
• «Using Custom Fonts in Silverlight»:
  http://silverlight.net/learn/learnvideo.aspx?video=69800 .
• «Sample Data in the WPF and Silverlight Designer» on MSDN:
  http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/30/sample-data-in-the-wpf-and-silverlight-designer.aspx .
• Learning the Visual Studio WPF and Silverlight DesignerThis contains tutorials and articles on layout, resources, data binding, sample data, debugging data bindings, object data sources, and master-detail forms.
• http://blogs.msdn.com/b/wpfsldesigner/archive/2010/01/15/learn.aspx .