न्यूनतम उपयोगकर्ता / हस्तलिखित कोड क्यों है और XAML में सब कुछ है?

Question

मुझे लगता है कि 90 के दशक में एमवीवीएम समुदाय ओओ प्रोग्रामर की तरह अति उत्साही हो गया है - यह एक मिथ्या नाम एमवीवीएम है जो किसी कोड का पर्याय नहीं है। मेरे बंद StackOverflow सवाल से :

कई बार मैं यहाँ पोस्ट के पार आता हूँ कि कोई कोड के बजाय XAML में बराबर करने की कोशिश कर रहा है। उनका एकमात्र कारण यह है कि वे अपना कोड 'क्लीन' के पीछे रखना चाहते हैं। अगर मैं गलत हूं तो मुझे सुधारो, लेकिन ऐसा नहीं है:

XAML को भी BAML में संकलित किया गया है - फिर रनटाइम में वैसे भी कोड में पार्स किया जाना है। XAML में संभावित रूप से अधिक बग बग हो सकते हैं क्योंकि उन्हें कंपाइलर द्वारा गलत समय पर नहीं उठाया जाएगा - गलत वर्तनी से - ये बग डिबग करने के लिए भी कठिन हैं। पहले से ही पीछे कोड है - जैसे कि यह या नहीं InitializeComponent (); चलाया जाना चाहिए और .gics फ़ाइल में यह कोड का एक गुच्छा होता है, हालांकि इसे छिपाया जा सकता है। क्या यह विशुद्ध रूप से मनोवैज्ञानिक है? मुझे संदेह है कि यह डेवलपर्स है जो एक वेब पृष्ठभूमि से आते हैं और कोड के विपरीत मार्कअप की तरह हैं।

संपादित करें: मैं XAML के बजाय कोड का प्रस्ताव नहीं करता - दोनों का उपयोग करें - मैं XAML में भी अपनी बाइंडिंग करना पसंद करता हूं - मैं सिर्फ WPF ऐप में esp के पीछे कोड लिखने से बचने के लिए हर संभव प्रयास करने के खिलाफ हूं - यह एक संलयन होना चाहिए दोनों इसका सबसे अधिक लाभ उठा सकते हैं।

UPDATE: इसका माइक्रोसॉफ्ट का आइडिया भी नहीं है, MSDN पर हर उदाहरण दिखाता है कि आप इसे दोनों में कैसे कर सकते हैं।

Answer 1

मैंने कभी किसी को एक्सएएमएल में सब कुछ डालने का सुझाव देने के बारे में नहीं सुना है।

वास्तव में, यह एक भयानक विचार होगा, आईएमओ।

समस्या, ऐतिहासिक रूप से, Winforms ऐप्स के पास उनके कोड में तर्क होने के पीछे से वहां नहीं थे, क्योंकि यह तर्क था । वहीं से VM का महत्व आता है। यह आपको उन हिस्सों को अलग करने की अनुमति देता है जो व्यू टू द मॉडल से एक साथ जुड़ते हैं।

इसलिए, देखें केवल वही संभालता है जो सबसे अच्छा है, जो UI है।

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

Comments

"नो कोड ...

— एवर

Answer 2

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

यह अनिवार्य प्रोग्रामिंग और घोषणात्मक डिजाइन के बीच एक स्वच्छ अलगाव प्रदान करता है।

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

Answer 3

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

Answer 4

सब कुछ आप xaml में कर सकते हैं करने के लिए सबसे बड़ा लाभ यह है कि यह सभी व्यवहार को एक जगह रखता है। हर बार डेवलपर को xaml और कोड के बीच कूदना पड़ता है और इसे समझना अधिक कठिन हो जाता है।

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

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

संपादित करें: टिप्पणियों से ऐसा लगता है जैसे मेरे पोस्ट को xaml के खिलाफ बहस के रूप में व्याख्या की जा रही है। मेरा इरादा इसके विपरीत बहस करना था। शुद्ध xaml हमेशा बेहतर होता है क्योंकि यह सभी व्यवहार को एक जगह रखता है। Xaml और कोड-पीछे का मिश्रण जटिल हो सकता है, इसलिए कोड-पीछे को कम करना आदर्श है। Xaml कई कारणों से शुद्ध कोड-पीछे बेहतर है। WPF और सिल्वरलाइट xaml में लिखे जाने के लिए डिज़ाइन किए गए हैं।

Comments

इस तर्क के अनुसार, हम सब कुछ सादे कोड में भी फिर से लागू कर सकते हैं।

— स्टीवन ज्यूरिस

@ स्टीवन ज्यूरिस कुछ मायनों में जो xaml और कोड के बिखरे हुए मिश्रण के लिए बेहतर होगा। मैंने इसे शुद्ध रूप से कोड और काम में देखा है।

— आकर्षित किया

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

— स्टीवन ज्यूरिस

@ सीनियर ज्यूरिस: मैं पूरी तरह से सहमत हूं। जब भी मैं कर सकता हूं मैं सब कुछ xaml में करता हूं। इसका मतलब है कि जब मैंने पोस्ट में कहा था, "मैं अंतिम उपाय के रूप में कोड-पीछे इलाज करने आया हूं।" मैं यह तर्क देने की कोशिश कर रहा हूं कि कम कोड-पीछे लगभग हमेशा बेहतर होता है। मेरा लक्ष्य यह कहना था कि शुद्ध ज़म्ल सबसे अच्छा है, लेकिन अधिकांश डिज़ाइन सिद्धांतों की तरह यह दुर्लभ परिस्थितियों में कोड-बैक में समझौता करने और तोड़ने के लिए ठीक है।

— आकर्षित किया

Answer 5

मुझे एक्सएएमएल का केवल बहुत ही सतही ज्ञान है, लेकिन यह मुझे चकित करता है कि कंपाइलर टाइपोस का पता नहीं लगाएगा।

मूल अंतर यह है कि XAML घोषणात्मक है , जबकि C # उदाहरण के लिए जरूरी है।

सीधे शब्दों में कहें:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

बनाम

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

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

हालांकि, इसका मतलब यह नहीं है, आपको XAML में सब कुछ पंच करने की कोशिश करनी चाहिए। सी # में कई उच्च स्तरीय निर्माण हैं जो एक घोषणात्मक शैली की अनुमति देते हैं।

अंत में, आप चाहते हैं कि आपका कोड छोटा और पढ़ने में आसान हो। इसलिए यदि आप XAML में कम कोड के साथ C # में एक ही चीज़ प्राप्त कर सकते हैं, तो C # का उपयोग करना तर्कसंगत है। ध्यान रखें कि, हालांकि, XAML कोड इस अर्थ में अधिक "पोर्टेबल" है कि यह उपयोग किए जाने वाले घटकों में बदलाव के लिए बहुत कम असुरक्षित है। .NET फ्रेमवर्क को दूर करना (उदाहरण के लिए बाइंडिंग कैसे लागू किया जाता है)।