सिल्वरलाइट समुदाय में XAML के कोड को फ़ाइल के पीछे जितना संभव हो सके कोड के रूप में रखने के लिए बहुत सारे प्रयास हैं। इसके पीछे असली प्रेरणा क्या है?XAML कोड से कोड को बाहर रखने का वास्तविक लाभ क्या है?
उदाहरण के लिए, किसी ईवेंट हैंडलर के बजाय कमांड का उपयोग करने का क्या फायदा है? अगर मेरे पास
<Button x:Name="SaveButton" Content="Save" Click="SaveButton_Click" />
...
private void SaveButton_Click(object sender, RoutedEventArgs e) {
_myViewModel.SaveChanges();
}
तो यह क्यों पसंद किया जाता है?
<Button x:Name="SaveButton" Content="Save" Command="{Binding SaveCommand}" />
कहाँ स्पष्ट रूप से मेरे विचार मॉडल में SaveCommand प्रभावी रूप से SaveChanges() आह्वान करने के लिए जा रहा है।
इससे परिस्थितियों का कारण बन सकता है जहां दृश्य 100% एक्सएएमएल है, यहां तक कि एक्सएएमएल में दृश्य मॉडल को तुरंत चालू करना, और दृश्य और दृश्य मॉडल के बीच कनेक्शन बाध्यकारी के माध्यम से पूरी तरह से किए जाते हैं। यकीन है कि यह साफ है, लेकिन यह और क्या है? लचीले? क्यूं कर? दृश्य को अभी भी उचित ViewModel के साथ काम करने की आवश्यकता है, इसलिए यदि दोनों के बीच का कनेक्शन मौजूद है और यह निहित है, तो इसे और अधिक स्पष्ट क्यों न करें? संकलन समय समर्थन खोने का भी नुकसान होता है। अगर मैं अपने बटन को एक ईवेंट हैंडलर पर लगाता हूं जो मौजूद नहीं है, तो संकलक मुझे बताएगा। अगर मैं एक अस्तित्वहीन आदेश से बंधे तो यह नहीं होगा।
मैं इस पर आपसे सहमत होने के इच्छुक हूं कि यदि आपके पास ऐसे प्रकार का एप्लिकेशन नहीं है जहां कमांड व्यापक रूप से उपयोगी हैं, तो मैं वास्तव में नहीं देखता कि अतिरिक्त टाइपिंग आपको क्या खरीदती है। जैसा कि आप कहते हैं, यह व्यूमोडेल की एक तरफ या किसी अन्य की टेस्टेबिलिटी को प्रभावित नहीं करता है। कुछ लोगों का मानना है कि एक बार जब आप कोई कोड-कोड कोड प्राप्त कर लेते हैं, तो आप उसमें तर्क को छिपाने में सक्षम नहीं होंगे जो व्यूमोडेल में होना चाहिए। –
प्राथमिकता परीक्षण की वजह से xaml/codebehind मार्कअप नहीं है। यह प्रश्न वास्तव में दिलचस्प होगा यदि आपके कोड उदाहरण में इन विकल्पों का परीक्षण करने के लिए दो दृष्टिकोण थे। यानी ViewModel.SaveChanges() और एक आईसीओएमएंड आधारित परीक्षण के लिए आपका परीक्षण। – itchi