เหตุใดจึงมีรหัสผู้ใช้ / ลายมือน้อยที่สุดและทำทุกอย่างใน XAML

ฉันรู้สึกว่าชุมชน MVVM มีความคลั่งไคล้เหมือนโปรแกรมเมอร์ OO ในยุค 90 - มันเป็นชื่อเรียก MVVM ที่เรียกชื่อผิดโดยไม่มีรหัส จากคำถาม StackOverflow ที่ปิดของฉัน:

หลายครั้งที่ฉันเจอโพสต์ที่นี่เกี่ยวกับคนที่พยายามทำสิ่งที่เทียบเท่าใน XAML แทนที่จะเป็นโค้ดด้านหลัง เหตุผลเดียวที่พวกเขาต้องการให้รหัสของพวกเขาอยู่เบื้องหลัง 'สะอาด' แก้ไขให้ฉันถ้าฉันผิด แต่ไม่ใช่ในกรณีที่:

XAML ถูกคอมไพล์ด้วย - ใน BAML - จากนั้นที่จะต้องมีการแยกวิเคราะห์โค้ดในรันไทม์ XAML อาจมีข้อผิดพลาดรันไทม์มากขึ้นเนื่องจากคอมไพเลอร์จะไม่ได้รับในเวลารวบรวม - จากการสะกดผิด - ข้อผิดพลาดเหล่านี้ยากต่อการดีบัก มีโค้ดอยู่แล้ว - ชอบหรือไม่ InitializeComponent (); จะต้องมีการเรียกใช้และไฟล์. gics ที่อยู่ในนั้นมีรหัสจำนวนมากถึงแม้ว่ามันจะถูกซ่อนอยู่ มันเป็นจิตวิทยาอย่างหมดจด? ฉันสงสัยว่าเป็นนักพัฒนาซอฟต์แวร์ที่มาจากพื้นหลังของเว็บและชอบมาร์กอัปซึ่งต่างกับรหัส

แก้ไข: ฉันไม่เสนอรหัสด้านหลังแทน XAML - ใช้ทั้งคู่ - ฉันชอบที่จะผูกมัดใน XAML ด้วย - ฉันแค่พยายามทุกวิถีทางที่จะหลีกเลี่ยงการเขียนโค้ดด้านหลัง esp ในแอป WPF - มันควรเป็นการหลอมรวมของ เพื่อให้ได้ประโยชน์สูงสุด

ปรับปรุง: มันไม่ได้เป็นความคิดของ Microsoft ทุกตัวอย่างใน MSDN แสดงให้เห็นว่าคุณสามารถทำได้ทั้งใน

ฉันไม่เคยได้ยินใครแนะนำให้ใส่ทุกอย่างใน XAML

อันที่จริงแล้วนั่นเป็นความคิดที่แย่มาก IMO

ปัญหาที่เกิดขึ้นในอดีตมาจาก Winforms ปพลิเคชันที่มีตรรกะในรหัสของพวกเขาที่อยู่เบื้องหลังที่ไม่ได้อยู่ที่นั่นเพราะมันเป็นตรรกะ นั่นคือสิ่งที่สำคัญของ VM มาจาก ช่วยให้คุณสามารถแยกชิ้นส่วนที่เชื่อมโยง View to the Model เข้าด้วยกัน

ดังนั้นมุมมองจะถูกทิ้งไว้เพื่อจัดการสิ่งที่ดีที่สุดซึ่งก็คือ UI

ทีนี้ถ้าคุณมีสถานการณ์ที่ UI ของคุณต้องการรหัสแล้วโดยทั้งหมดไปให้มันและวางไว้ในรหัสของคุณที่อยู่เบื้องหลัง อย่างไรก็ตามฉันจะบอกว่าสำหรับสถานการณ์ 95% ในนั้นคุณน่าจะดีกว่าที่จะทิ้ง UI ไว้ในไฟล์มาร์กอัปและถ้าคุณต้องการรหัสบางอย่างมันอาจเป็นตรรกะที่คุณพยายามจะเขียน ที่เหลือให้เหมาะสมกับมุมมองโมเดลมากขึ้น ข้อยกเว้นสำหรับสิ่งนี้คือสิ่งต่าง ๆ เช่นพฤติกรรม แต่เป็นสัตว์ที่แยกจากกันโดยสิ้นเชิงและต้องการสถานที่พิเศษ (เช่นไม่ใช่รหัสของคุณ)

ในการตอบคำถามของคุณโดยตรงและสมมติว่าเมื่อคุณพูดว่า "code" ซึ่งในทุก ๆ ครั้งที่คุณอ้างถึง code-behind (รหัสที่อยู่ในคลาส control visual) เหตุผลก็คือเพื่อให้ส่วนต่อประสานผู้ใช้ของคุณสามารถนำไปใช้ได้ทั้งหมด และจัดการใน Blend โดยใช้เทคโนโลยีเดียวเท่านั้น สมมติฐานคือผู้ออกแบบ UX ของคุณไม่ใช่นักพัฒนาและไม่ต้องการทำงานในโค้ดและพวกเขาเป็นเลย์เอาต์และผู้เชี่ยวชาญ XAML ซึ่งต่างจากผู้เชี่ยวชาญด้านการเข้ารหัส หากคุณใช้งานทุกอย่างโดยไม่ใช้โค้ดคุณสามารถมอบเครื่องมือที่พวกเขาต้องการเพื่อใช้ในการออกแบบภาษาของพวกเขา

มันมีการแยกทำความสะอาดระหว่างการเขียนโปรแกรมที่จำเป็นและการออกแบบที่เปิดเผย

นี่คือเหตุผลที่ผลักดันให้มี "พฤติกรรม" ใน Silverlight และ WPF - แทนที่จะทิ้งรหัสลงในโค้ด - หลังทำให้เกิดพฤติกรรมของโมดูลที่สามารถนำกลับมาใช้ใหม่ได้ ถ้าคุณทำเช่นนั้น Blend จะช่วยให้คุณสามารถลากและวางมันลงบนส่วนควบคุมได้ ตอนนี้แทนที่จะมีชิ้นส่วนที่เคลื่อนไหวเพียงครั้งเดียวเป็นส่วนหนึ่งของการควบคุมแบบ all-in-XAML คุณได้ทำให้ชิ้นส่วนที่เคลื่อนไหวอยู่ในคอนเทนเนอร์ที่ดีซึ่งสามารถจัดการได้โดยใช้เครื่องมือออกแบบ

จากประสบการณ์ของฉันสิ่งนี้มักเกิดขึ้นกับการพยายามใช้ตรรกะที่ซับซ้อนใน XAML ทริกเกอร์เพื่อป้องกันไม่ให้โค้ดล้าหลังเมื่อวิธีการที่ดีกว่าและเรียบง่ายกว่าคือการใช้ตรรกะนั้นใน - ไม่ได้อยู่ในมุมมอง -model

ข้อดีอย่างหนึ่งที่ยิ่งใหญ่ที่สุดในการทำทุกสิ่งที่คุณทำได้ใน xaml คือมันช่วยให้พฤติกรรมทั้งหมดอยู่ในที่เดียว ทุกครั้งที่ผู้พัฒนาต้องข้ามไปมาระหว่าง xaml และรหัสมันจะยากที่จะเข้าใจ

ฉันอยู่ในทีม WPF ที่ไม่ได้ลดลำดับความสำคัญของโค้ด มีมากกว่าสองสามครั้งที่การดีบักนั้นยากกว่าเนื่องจากตัวจัดการเหตุการณ์บางตัวจัดการควบคุมและมันก็ไม่ปรากฏทันทีเพราะพฤติกรรมนั้นกระจัดกระจายในสองไฟล์

ที่กล่าวว่าฉันเชื่อว่าคุณมีสิทธิ์ที่จะคิดว่าบางครั้งคุณจะดีกว่าประนีประนอมกับหลักการออกแบบ บางสิ่งทำได้ยากมากใน xaml ฉันใช้เวลาหลายชั่วโมงหรือหลายวันในการพยายามทำให้พฤติกรรมทำงานใน xaml ที่ฉันสามารถทำได้ในเวลาที่น้อยลงโดยใช้ code-behind ฉันได้รับการปฏิบัติที่ล้าหลังเป็นทางเลือกสุดท้าย แต่ฉันจะไม่บอกใครสักคนว่าพวกเขาไม่ควรใช้มัน มันเป็นข้อเสียอีกอย่างหนึ่งที่วิศวกรที่ดีต้องเข้าใจ

แก้ไข: จากความคิดเห็นดูเหมือนว่าโพสต์ของฉันถูกตีความว่าเป็นการโต้เถียงกับ xaml ความตั้งใจของฉันคือการโต้แย้งตรงกันข้าม xaml บริสุทธิ์มักเป็นที่นิยมมากกว่าเพราะมันเก็บพฤติกรรมทั้งหมดไว้ในที่เดียว การผสมผสานระหว่าง xaml และ code-behind สามารถทำให้เกิดความสับสนได้ Xaml นั้นดีกว่าการใช้โค้ดบริสุทธิ์ด้วยเหตุผลหลายประการ WPF และ Silverlight ได้รับการออกแบบให้เขียนด้วย xaml

ฉันมีความรู้ผิวเผินเกี่ยวกับ XAML เพียงอย่างเดียว แต่มันทำให้ฉันงุนงงว่าคอมไพเลอร์จะไม่ตรวจจับความผิดพลาด

ความแตกต่างพื้นฐานคือ 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วิธีการอาจถูกเปลี่ยนชื่อตัวอย่างเช่นความสัมพันธ์ระหว่างเด็กกับผู้ปกครองนั้นเป็นแกนหลักของรูปแบบความหมายและมีการแสดงเช่นในข้อมูลโค้ดที่ประกาศ มันอยู่ไกลจากการใช้งานซึ่งช่วยให้การเพิ่มประสิทธิภาพมากภายใต้เช่น instantiation ขี้เกียจสมบูรณ์โปร่งใส
การเขียนโปรแกรมการสำแดงมีข้อดีหลายประการ มันกระชับแสดงออกและใกล้เคียงกับโมเดลของคุณมากขึ้น ฉันจะไปไกลเท่าที่มันจะดีกว่า

อย่างไรก็ตามนี่ไม่ได้หมายความว่าคุณควรพยายามต่อยทุกอย่างเป็น XAML C # มีโครงสร้างระดับสูงมากมายที่อนุญาตให้มีสไตล์ที่เปิดเผยได้

ในที่สุดคุณต้องการให้รหัสของคุณสั้นและอ่านง่าย ดังนั้นหากคุณสามารถบรรลุสิ่งเดียวกันใน C # ด้วยรหัสน้อยกว่าใน XAML การใช้ C # เป็นตรรกะ โปรดจำไว้ว่าอย่างไรก็ตามรหัส XAML นั้น "พกพา" ได้มากกว่าในแง่ที่ว่ามีความเสี่ยงน้อยกว่าต่อการเปลี่ยนแปลงในส่วนประกอบที่ใช้ทำให้โครงสร้างของ. NET อยู่ในกรอบแคบลง (ตัวอย่างเช่น