การใช้ MVVM มีเงื่อนไขใดบ้าง

Model View-Model ได้รับการพัฒนาโดย Microsoft เพื่อกำหนดเป้าหมายแพลตฟอร์มการพัฒนา UI ซึ่งรองรับการเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์โดยเฉพาะ Windows Presentation Foundation (WPF) และ Silverlight บนแพลตฟอร์ม. NET โดยใช้ภาษา XAML และ. NET ในหลายปีที่ผ่านมาเฟรมเวิร์ก Javascript จำนวนมากเช่น Angular, Knockout และ ExtJS ได้นำรูปแบบนี้มาใช้

เช่นเดียวกับรูปแบบซอฟต์แวร์ส่วนใหญ่ MVVM มีการใช้งานที่เหมาะสมและใช้ในทางที่ผิด การใช้ MVVM มีเงื่อนไขใดบ้าง เมื่อไรที่ไม่ควรทำ

MVVMมีวัตถุประสงค์เพื่อใช้ในกรณีที่ต้องการการโต้ตอบกับผู้ใช้ที่ซับซ้อนโดยใช้ UI ความเที่ยงตรงสูง (เช่นWPF )

MVVM มีเป้าหมายที่แพลตฟอร์มการพัฒนา UI ที่ทันสมัย ​​(Windows Presentation Foundation หรือ WPF และ Silverlight) ซึ่งมีนักพัฒนาประสบการณ์ผู้ใช้ (UXi) ที่มีความต้องการแตกต่างจากผู้พัฒนา "ดั้งเดิม" มากกว่า (เช่นมุ่งเน้นไปที่ตรรกะทางธุรกิจและ การพัฒนาส่วนหลัง) View-Model ของ MVVM นั้นเป็น“ ตัวแปลงค่าบนเตียรอยด์” โดยพื้นฐานแล้วหมายความว่า View-Model มีหน้าที่เปิดเผยวัตถุข้อมูลจาก Model ในลักษณะที่การจัดการและบริโภควัตถุเหล่านั้นทำได้ง่าย ในแง่นี้ View-Model เป็นรุ่นมากกว่า View และจัดการได้มากที่สุดหากไม่ใช่ตรรกะการแสดงผลทั้งหมดของ View

MVVM ได้รับการออกแบบมาเพื่อใช้ประโยชน์จากฟังก์ชั่นเฉพาะใน WPF เพื่อช่วยในการแยกการพัฒนาเลเยอร์ของมุมมองออกจากส่วนที่เหลือของรูปแบบได้ดียิ่งขึ้นโดยการลบ "code-behind" ทั้งหมดออกจากเลเยอร์ View แทนที่จะต้องการให้ผู้ออกแบบเชิงโต้ตอบเพื่อเขียนรหัสดูพวกเขาสามารถใช้ภาษา XAML มาร์กอัป WPF ดั้งเดิมและสร้างการเชื่อมโยงกับ ViewModel ซึ่งเขียนและดูแลโดยนักพัฒนาแอปพลิเคชัน การแยกบทบาทนี้ช่วยให้ผู้ออกแบบเชิงโต้ตอบสามารถมุ่งเน้นที่ความต้องการของ UX ได้มากกว่าการเขียนโปรแกรมหรือตรรกะทางธุรกิจซึ่งทำให้ชั้นของแอพพลิเคชั่นได้รับการพัฒนาในหลาย ๆ กระแสงาน

สำหรับ UI ที่ไม่จำเป็นต้องมีการโต้ตอบเช่นนี้ MVVM อาจเกินความสามารถ MVP อาจเป็นทางเลือกที่เป็นธรรมชาติมากกว่า สำหรับเว็บแอปพลิเคชัน MVC นั้นเหมาะสมกว่า สำหรับแอปพลิเคชันขนาดเล็กมากที่จะไม่ขยายใหญ่ขึ้น (เช่นอรรถประโยชน์ Winforms ขนาดเล็ก) การเขียนโค้ดที่เพียงพอ

บางครั้ง MVVM อาจเป็นกับดัก จากประสบการณ์ของฉันมันชอบแอพพลิเคชั่นคล้าย CRUD (ฟอร์มเหนือข้อมูล) เทียบกับ UIs ที่มุ่งเน้นงานมากขึ้น ฉันไม่ได้บอกว่ามันหมายถึงสถาปัตยกรรมที่ไม่ดีสำหรับส่วนหลัง / เลเยอร์อื่น ๆ ในแอปพลิเคชัน แต่ฉันได้เห็นแอปพลิเคชัน MVVM จำนวนมากที่มาพร้อมกับสถาปัตยกรรม "ไฟ DDD" ฉันไม่รู้ว่าทำไมอาจเป็นเพราะการผูกนั้นง่ายมากและมันง่ายมากที่จะติดตั้งแอปพลิเคชันด้วย ORM และ MVVM / Binding โดยใช้วัตถุโดเมน POCO / Anemic

MVVM เป็นตัวช่วยแบนด์สำหรับเลเยอร์การผูกข้อมูลที่ออกแบบมาไม่ดี โดยเฉพาะอย่างยิ่งมันได้เห็นการใช้งานจำนวนมากในโลก WPF / silverlight / WP7 เนื่องจากข้อ จำกัด ในการผูกข้อมูลใน WPF / XAML

จากนี้ไปฉันจะสมมติว่าเรากำลังพูดถึง WPF / XAML เพราะสิ่งนี้จะทำให้สิ่งต่าง ๆ ชัดเจนยิ่งขึ้น ให้ดูที่ข้อบกพร่องบางอย่างที่ MVVM กำหนดไว้เพื่อแก้ปัญหาใน WPF / XAML

รูปร่างข้อมูลเทียบกับรูปร่าง UI

'VM' ใน MVVM สร้างชุดของวัตถุที่กำหนดใน C # ที่แมปไปยังชุดของวัตถุนำเสนอที่กำหนดใน XAML โดยทั่วไปแล้ววัตถุ C # เหล่านี้จะเชื่อมต่อกับ XAML ผ่านคุณสมบัติ DataContext บนวัตถุการนำเสนอ

ด้วยเหตุนี้กราฟวัตถุ viewmodel จำเป็นต้องแมปลงในกราฟวัตถุการนำเสนอของแอปพลิเคชันของคุณ ไม่ได้หมายความว่าการแมปจำเป็นต้องเป็นแบบหนึ่งต่อหนึ่ง แต่ถ้าการควบคุมรายการถูกควบคุมโดยตัวควบคุมหน้าต่างจะต้องมีวิธีที่จะได้รับจากวัตถุ DataContext ของหน้าต่างไปยังวัตถุที่อธิบายข้อมูลของรายการนั้น

กราฟวัตถุ viewmodel decouples กราฟวัตถุรูปแบบจากกราฟวัตถุ ui ประสบความสำเร็จ แต่ค่าใช้จ่ายของเลเยอร์ viewmodel เพิ่มเติมที่จะต้องสร้างและบำรุงรักษา

ถ้าฉันต้องการย้ายข้อมูลบางอย่างจากหน้าจอ A ไปยังหน้าจอ B ฉันต้องยุ่งกับ viewmodels ในความคิดของนักธุรกิจนี่คือการเปลี่ยนแปลง UI มันควรจะเกิดขึ้นอย่างหมดจดในโลกของ XAML น่าเศร้าที่มันไม่สามารถทำได้ ยิ่งแย่ไปกว่านั้นขึ้นอยู่กับว่าโครงสร้างมุมมองเป็นอย่างไรและการเปลี่ยนแปลงของข้อมูลเป็นอย่างไรจำเป็นต้องมีการเปลี่ยนเส้นทางข้อมูลอีกเล็กน้อยเพื่อให้การเปลี่ยนแปลงนี้ประสบผลสำเร็จ

หลีกเลี่ยงการผูกข้อมูลที่ไม่แสดงออก

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

หากคุณต้องการผูกคุณสมบัติใน C # กับสิ่งที่ซับซ้อนกว่านั้นคุณก็โชคไม่ดี ฉันไม่เคยเห็นแอป WPF ที่ไม่มีตัวแปลงการผูกข้อมูลที่เปลี่ยนเป็นจริง / เท็จให้เป็น Visible / Collapsed แอป WPF หลายแห่งมีแนวโน้มที่จะมีสิ่งที่เรียกว่า NegatingVisibilityConverter หรือที่คล้ายกันซึ่งพลิกขั้ว นี่ควรเป็นการปิดระฆังปลุก

MVVM ให้แนวทางในการจัดโครงสร้างรหัส C # ของคุณที่สามารถใช้เพื่อให้ราบรื่นกับข้อ จำกัด นี้ คุณสามารถแสดงคุณสมบัติใน viewmodel ของคุณที่ชื่อว่า SomeButtonVisibility และผูกเข้ากับการมองเห็นของปุ่มนั้น XAML ของคุณสวยและน่ารักตอนนี้ ... แต่คุณทำตัวเป็นเสมียนแล้ว - ตอนนี้คุณต้องแสดง + อัปเดตการเชื่อมโยงสองแห่ง (UI และรหัสใน C #) เมื่อ UI ของคุณวิวัฒนาการ หากคุณต้องการปุ่มเดียวกันบนหน้าจออื่นคุณจะต้องแสดงคุณสมบัติที่คล้ายกันในโมเดลโมเดลที่หน้าจอนั้นสามารถเข้าถึงได้ แย่กว่านั้นฉันไม่สามารถดู XAML และดูว่าปุ่มจะปรากฏให้เห็นอีกต่อไปเมื่อใด ทันทีที่การมัดกลายเป็นเรื่องไม่สำคัญฉันต้องทำงานนักสืบในรหัส C #

การเข้าถึงข้อมูลมีการกำหนดขอบเขตอย่างจริงจัง

เนื่องจากโดยทั่วไปข้อมูลเข้าสู่ UI ผ่านคุณสมบัติ DataContext จึงเป็นการยากที่จะแสดงข้อมูลทั่วโลกหรือเซสชันอย่างสม่ำเสมอตลอดทั้งแอปของคุณ

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

สิ่งที่ฉันต้องการจะทำคือใช้คำว่า "CurrentUser" ในการผูกข้อมูลอย่างอิสระเพื่ออ้างถึงผู้ใช้ที่เข้าสู่ระบบในปัจจุบัน แต่ฉันต้องตรวจสอบให้แน่ใจว่าDataContext ทุกตัวให้วิธีในการเข้าถึงวัตถุผู้ใช้ปัจจุบัน MVVM สามารถรองรับสิ่งนี้ได้ แต่รูปแบบการดูจะไม่เป็นระเบียบเพราะพวกเขาทั้งหมดต้องให้การเข้าถึงข้อมูลทั่วโลกนี้

ตัวอย่างที่ MVVM อยู่เหนือ

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

วัตถุโมเดลของคุณไม่ควรรู้เกี่ยวกับผู้ใช้ที่เข้าสู่ระบบในปัจจุบัน - พวกเขาจะแสดงระเบียนผู้ใช้ในฐานข้อมูลของคุณ แต่อย่างใดผู้ใช้ที่เข้าสู่ระบบในปัจจุบันจำเป็นต้องเปิดเผยการผูกข้อมูลภายในแถวรายการของคุณ MVVM กำหนดว่าเราควรสร้างวัตถุ viewmodel สำหรับแต่ละแถวรายการที่ประกอบด้วยผู้ใช้ที่เข้าสู่ระบบในปัจจุบันด้วยผู้ใช้ที่เป็นตัวแทนของแถวรายการนั้นจากนั้นเปิดเผยคุณสมบัติที่ชื่อว่า "DeleteButtonVisibility" หรือ "CanDelete" บนวัตถุ viewmodel เกี่ยวกับตัวแปลงผูกพัน)

วัตถุนี้กำลังจะดูน่ากลัวมากเหมือนวัตถุผู้ใช้ในวิธีอื่น ๆ ส่วนใหญ่ - มันอาจต้องสะท้อนคุณสมบัติของวัตถุแบบจำลองผู้ใช้ทั้งหมดและส่งต่อการปรับปรุงไปยังข้อมูลนั้นเมื่อมีการเปลี่ยนแปลง สิ่งนี้ให้ความรู้สึกลำบากมาก - อีกครั้ง MVVM ทำให้คุณเป็นพนักงานโดยบังคับให้คุณรักษาวัตถุที่ใช้งานได้จริงของผู้ใช้นี้

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

ยิ่งแย่กว่านั้นเลเยอร์นี้จะปรับตามความซับซ้อนของ UI ของคุณไม่ใช่กับความซับซ้อนของตัวแบบข้อมูลของคุณ บ่อยครั้งที่ข้อมูลเดียวกันถูกแสดงในหลาย ๆ ที่และใน UI ของคุณ - ซึ่งไม่เพียง แต่เพิ่มเลเยอร์เท่านั้น แต่ยังเพิ่มเลเยอร์ที่มีพื้นที่พื้นผิวพิเศษมากมาย!

สิ่งต่าง ๆ จะเป็นไปได้อย่างไร

ในกรณีที่อธิบายไว้ข้างต้นฉันอยากจะบอกว่า:

<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />

ผู้ใช้ปัจจุบันจะถูกเปิดเผยทั่วโลกกับ XAML ทั้งหมดในแอปของฉัน รหัสจะอ้างถึงคุณสมบัติใน DataContext สำหรับแถวรายการของฉัน การเปิดเผยจะแปลงจากบูลีนโดยอัตโนมัติ การอัพเดตใด ๆ กับ Id, CurrentUser.IsAdmin, CurrentUser หรือ CurrentUser.Id จะทำให้เกิดการอัปเดตการมองเห็นปุ่มนี้ ง่าย peasy

แต่ WPF / XAML บังคับให้ผู้ใช้สร้างระเบียบสมบูรณ์ เท่าที่ฉันจะบอกได้นักสร้างสรรค์บล็อกเกอร์บางคนตบชื่อเรื่องนั้นและชื่อนั้นก็คือ MVVM อย่าหลงกล - มันไม่ได้อยู่ในชั้นเรียนเดียวกันกับรูปแบบการออกแบบของ GoF นี่เป็นแฮ็คที่น่าเกลียดในการหลีกเลี่ยงระบบการเชื่อมข้อมูลที่น่าเกลียด

(บางครั้งวิธีการนี้เรียกว่า "ฟังก์ชั่นการตอบโต้การเขียนโปรแกรม" ในกรณีที่คุณกำลังมองหาการอ่านเพิ่มเติม)

สรุปแล้ว

หากคุณต้องทำงานใน WPF / XAML ฉันยังไม่แนะนำ MVVM

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

MVVM บอกให้คุณจัดโครงสร้างโค้ดของคุณด้วยวิธีที่ละเอียดกว่าและบำรุงรักษาได้น้อยกว่า

แทนที่จะเป็น MVVM ให้สร้างสิ่งต่าง ๆ เพื่อช่วยให้คุณประมาณประสบการณ์ที่ดี: พัฒนาข้อตกลงสำหรับการเปิดเผยสถานะทั่วโลกให้กับ UI ของคุณอย่างสม่ำเสมอ สร้างเครื่องมือของคุณเองจากตัวผูกรวมหลายพันธะ ฯลฯ ที่ช่วยให้คุณแสดงนิพจน์ที่ซับซ้อนยิ่งขึ้น สร้างห้องสมุดตัวแปลงที่มีผลผูกพันไว้ให้ตัวเองเพื่อช่วยให้คดีข่มขู่ร่วมเจ็บปวดน้อยลง

ดียิ่งขึ้น - แทนที่ XAML ด้วยสิ่งที่แสดงออกมากขึ้น XAML เป็นรูปแบบ XML ที่ง่ายมากสำหรับการทำให้วัตถุ C # เป็นอินสแตนซ์ - มันไม่ยากที่จะเกิดขึ้นกับตัวแปรที่แสดงออกมากขึ้น

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

ฉันชอบ MVVM จริงๆและฉันพบความท้าทายที่สร้างแรงบันดาลใจและเห็นประโยชน์มากมาย แต่ ...

1. สำหรับแอปพลิเคชันหรือเกมที่ต้องใช้ UI / รหัสการโต้ตอบจำนวนมากเพื่อเพิ่มพฤติกรรมที่กำหนดเองจำนวนมากในขณะที่รักษาความสมบูรณ์ - มันมักจะดีกว่าที่จะใช้ MVVM ที่สกปรกเล็กน้อย - ใช้เมื่อมันเป็นประโยชน์หรือเป็นศูนย์กลางข้อมูลมากกว่า พื้นที่ศูนย์กลางการโต้ตอบของรหัส สมมติว่าคุณต้องการสร้างตัวควบคุมและย้ายไปมาระหว่างตัวควบคุมหลักอื่นหรือแคชอย่างอื่น ...

2. มีเส้นโค้งการเรียนรู้ที่ค่อนข้างสูงดังนั้นหากคุณไม่มีเวลาวางแผนที่จะพัฒนาจำนวนมากใน WPF / SL มีนักออกแบบที่มีทักษะในการผสมผสานรู้สึกว่าจำเป็นต้องเขียนรหัสทดสอบสำหรับ UI ของคุณหรือไม่ก็คาดหวังว่าจะบำรุงรักษาเป็นเวลาหลายปี โครงการ - อาจไม่ได้ผล

3. มีนักออกแบบหลายคนที่รู้จัก Blend แต่โครงการทั้งหมดนั้นไม่คุ้มค่าที่จะมุ่งเน้นไปที่การทดสอบอัตโนมัติในเลเยอร์การนำเสนอเนื่องจากจะต้องมีการทดสอบด้วยตนเองแล้วและนั่นคือวิธีที่คุณจะพบข้อบกพร่องที่สำคัญ

4. เป็นการลงทุนจริงๆ คุณต้องเข้าใจพื้นฐานของ WPF / SL และ XAML ก่อนจากนั้นหาวิธีที่จะทำการผูกให้ถูกต้องเชื่อมต่อกับ vms ในบางลำดับรับคำสั่งของคุณเลือกกรอบในกรณีส่วนใหญ่ เป็นปัญหาเนื่องจากการออกใบอนุญาตสร้างไลบรารี่ sippets เพื่อให้โค้ดมีประสิทธิภาพเพียงเพื่อจะพบว่าแพลตฟอร์มนั้นทำงานได้ไม่ดีกับการผูกและจำเป็นต้องสร้างไลบรารี่ของพฤติกรรมที่ทำให้คุณได้รับสิ่งที่คุณต้องการ

โดยรวมแม้ว่า - ถ้าคุณเอาชนะอุปสรรคทั้งหมดและกลายเป็นผู้เชี่ยวชาญในรูปแบบที่เป็นธรรม - มันทั้งหมดจ่ายกลับมาในความชัดเจนการบำรุงรักษาและ ... สิทธิเป้อเย้อ? :)

ฉันเป็นโปรแกรมเมอร์ WPF / Silverlight มานานหลายปีในการสร้างแอพพลิเคชั่นขนาดใหญ่เช่นระบบการซื้อขายบน MVVM

สำหรับฉันเมื่อหลายปีผ่านไปฉันได้เรียนรู้ว่า MVVM ที่เข้มงวดกินเวลาและค่าใช้จ่าย โดยเข้มงวดฉันหมายถึงกฎเช่น "ไม่มีรหัสอยู่เบื้องหลัง"

มันเป็นไปไม่ได้เลยนอกจากแอพฟอร์ม / ฐานข้อมูลพื้นฐานที่สุดที่จะไม่ใช้โค้ด

นักออกแบบของคุณจะระบุบางอย่างในวันแรกที่ไม่สามารถทำได้ด้วยการควบคุมมาตรฐานดังนั้นคุณต้องสร้างชุดการควบคุมที่กำหนดเองหรือตัดการควบคุมที่มีอยู่เพื่อสนับสนุนกระบวนทัศน์การโต้ตอบในขณะที่ทำงานกับ MVVM

ฉันได้เขียนการควบคุม UI แบบ swish ทุกประเภทโดยใช้คณิตศาสตร์ความเฉื่อยท่าทาง ฯลฯ และการทำงานอย่างหนัก

แต่นี่คือรหัสทั้งหมดมันไม่ได้อยู่ในมุมมอง คุณต้องจัดการกับการคลิกที่ปุ่มการเลื่อนลากและอื่น ๆ แต่ทั้งหมดนั้นถูกห่อหุ้มไว้อย่างดีในชุดควบคุมซึ่งทำให้โค้ดนี้ไม่เป็นไร

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

เป้าหมายของ MVVM คือการแยกตรรกะแอปพลิเคชัน / ธุรกิจออกจากตรรกะ UI ระบบผูกพันและ MVVM เป็นวิธีที่ดีในการทำเช่นนี้

เป้าหมายอื่น ๆ โน้มน้าวเช่นนักออกแบบ XAML บนโต๊ะหนึ่งโปรแกรมเมอร์ C # ที่อีกคนหนึ่งทำงานใน Blend อีกคนใน VS เป็นความผิด

ความสามารถในการออกแบบ UI อย่างรวดเร็วเป็นอีกหนึ่งความเข้าใจผิด มันไม่เคยเกิดขึ้นการเพิ่มประสิทธิภาพก่อนวัยอันควร การทำงานซ้ำที่สำคัญใด ๆ จำเป็นต้องใช้เวลามากในการทำงานกับโมเดลมุมมอง การปรับแต่งเป็นสิ่งหนึ่ง แต่ไม่สามารถทำการยกเครื่อง UI ได้อย่างรวดเร็ว โมเดลของมุมมองจะต้องสอดคล้องกับกระบวนทัศน์การโต้ตอบดังนั้นการมีเพศสัมพันธ์จึงแน่นกว่าที่คุณคิด

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

มิฉะนั้นคุณจะกลายเป็นผู้ออกแบบภาพเคลื่อนไหวอนิเมชั่นและอื่น ๆ อีกมากมายเพียงเพราะความคิดที่ว่า MVVM จะทำให้มันเกิดขึ้นได้อย่างไม่น่าเชื่อ

MVVM เหมือนสิ่งส่วนใหญ่ในชีวิตมีจุดหวานอยู่ระหว่างสองขั้ว

สิ่งที่สำคัญที่สุดในการออกแบบซอฟต์แวร์คือการจัดส่งผลิตภัณฑ์ของคุณในช่วงต้นค้นหาว่ามีการใช้คุณลักษณะใดบ้าง UI ใดที่ใช้งานได้ดีและไม่เขียนโค้ดที่สวยงามสำหรับผลิตภัณฑ์ที่ไม่มีใครใช้

หากแอปพลิเคชันของคุณต้องการให้คุณผูกข้อมูลมากเกินไปในแบบเรียลไทม์ MVVM สามารถเข้ามาได้เพราะเป็นการแนะนำบทคัดย่อที่ทำให้กระบวนการทำงานช้าลงและสมมติว่าเรากำลังพูดถึง WPF / Silverlight / WP7 ในตอนนี้ เครื่องยนต์ในปัจจุบันนั้นไม่ค่อยมีประสิทธิภาพ แม้ว่าการปรับปรุงกำลังจะมา

MVVM อย่างที่มันเป็นไม่ใช่แค่ส่วนเดียวของสมการที่คุณต้องพิจารณา Pure MVVM ต้องได้รับการสนับสนุนด้วยโครงสร้างพื้นฐานเช่นรูปแบบ Mediator เพื่อให้คุณสามารถสื่อสารข้าม ViewModels ที่ไม่ได้เชื่อมต่อได้

แม้จะมีความคิดเห็นของ blucz ข้างต้น MVVM อยู่ในแนวของรูปแบบ GoF หากคุณดูที่รูปแบบ MVVM นั้นเทียบเท่ากับรูปแบบ Model View Passive Presenter ซึ่งปรากฏในเวลาเดียวกับ MVVM คุณมักจะบ่นเกี่ยวกับความซับซ้อนของ MVVM อย่างหมดจดเพราะพวกเขาไม่เข้าใจวิธีการใช้ MVVM

อีกพื้นที่ที่ฉันพบปัญหาเกี่ยวกับ MVVM คือที่ที่คุณต้องรวมเทคโนโลยีของ บริษัท อื่นที่ไม่ได้ออกแบบมาเพื่อรองรับ (เช่นเฟรมเวิร์ก UII สำหรับ MS Dynamics) บางครั้งคุณต้องถามตัวเองว่ามันคุ้มค่ากับความเจ็บปวดจากการ "แฮ็ค" รอบ ๆ เทคโนโลยีอื่นหรือไม่เพื่อทำงานกับ MVVM

หากคุณกำลังผสมและจับคู่บางอย่างเช่น Win Forms ในโซลูชัน WPF ของคุณส่วนนั้นของโซลูชันนั้นอาจไม่เหมาะสำหรับ MVVM เช่นกัน ฉันหวังว่าสิ่งนี้จะช่วยให้คุณมีความคิดบางอย่างเกี่ยวกับพื้นที่ที่ MVVM ใช้ไม่ได้

การใช้ MVVM ไม่สมเหตุสมผลเมื่อ:

• คุณไม่ได้ทำงานกับ WPF หรือ Silverlight
• คุณกำลังทดสอบแนวคิด

แค่นั้นแหละ. ฉันคิดไม่ออกเลยว่าทำไมคุณถึงไม่ใช้ MVVM เมื่อทำงานกับ WPF / Silverlight ยกเว้นว่าคุณกำลังทดสอบหรือแก้ไขจุดบกพร่องบางอย่างในโครงการแยกต่างหาก ฉันพบรูปแบบการออกแบบที่เหมาะสำหรับการพัฒนา WPF / Silverlight เนื่องจากวิธีการทำงานของ XAML Bindings

ประเด็นทั้งหมดของ MVVM คือแอปพลิเคชันทั้งหมดของคุณทำงานใน ViewModels ของคุณและ Views ของคุณเป็นเลเยอร์สวย ๆ ที่ผู้ใช้สามารถใช้เพื่อโต้ตอบกับ ViewModels ของคุณ คุณต้องการคลิกปุ่มจริง ๆ แล้วคุณกำลังเรียกใช้วิธีการ ViewModel คุณต้องการเปลี่ยนหน้าคุณกำลังเปลี่ยนคุณสมบัติ CurrentPage ใน ViewModel

ฉันใช้ MVVM สำหรับการพัฒนา WPF / Silverlight ทั้งหมดแม้แต่โครงการหน้าเดียวขนาดเล็กที่เรียบง่ายถึงแม้ว่าฉันจะใช้ MVVM แตกต่างกันไปตามขนาดของโครงการและสิ่งที่ฉันต้องการ ครั้งหนึ่งที่ฉันทำแอพขนาดเล็กที่ไม่มี MVVM ฉันก็เสียใจที่ได้รับมัน (ภายหลังได้รับการปรับสภาพให้ใช้ MVVM ในขณะที่เพิ่มการอัปเดต)

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

ฉันทำตัวเป็นบ้ากับ RoR และข้ามการทำอะไรกับ ASP.NET Webforms ไปได้ แต่เมื่อ ASP.NET MVC ออกมาฉันพยายามที่จะเรียนรู้ให้มากที่สุดเท่าที่จะทำได้โดยใช้ ASP.NET MVC In Action หนังสือและ codecampserver เป็นตัวอ้างอิง . แม้ว่ามันจะเป็นรูปแบบที่แตกต่างกันฉันใช้หลายสิ่งที่ฉันเรียนรู้จากหนังสือ In Action ในการพัฒนา SL / MVVM

เมื่อฉันเริ่มทำงานกับ Silverlight ฉันรู้สึกประหลาดใจกับความเปลือยเปล่าของมันและรู้สึกว่ามันเป็นข้อกำหนดที่จะเลือกหนึ่งในหลายเฟรมเวิร์กที่มีให้แต่งตัว ฉันเห็นว่านี่เป็นปัญหากับคนที่ยอมแพ้ในการเรียนรู้ MVVM

ฉันเริ่มต้นด้วยMVVM-Lightที่ยอดเยี่ยมซึ่งช่วยให้ฉันเข้าใจรูปแบบการขาย หลังจากนั้นฉันก็เริ่มทำงานกับ Caliburn Micro และจากนั้นไฟก็สว่างขึ้น สำหรับฉันCaliburn Microนั้นเหมือนกับการใช้ ASP.NET MVC ผ่าน ASP.NET Webforms ดังนั้นแม้สำหรับแอปพลิเคชันตัวอย่างขนาดเล็กฉันสร้างโครงการ NuGet CM และฉันปิดและทำงานอยู่ ฉันปฏิบัติตามแนวทางแรกของ ViewModel และทำให้ Views ของฉันเป็นใบ้และง่ายต่อการใช้งานใน Blend VM ของฉันทดสอบได้ถ้าคุณอยู่ในนั้นและด้วย CM มันค่อนข้างง่ายที่จะยกเลเยอร์หน้าจอที่ซับซ้อน

คุณอาจสนุกกับการตรวจสอบทางเลือกนี้ ตัวเลือกนี้จะติดตั้งวิธี WPF ของ databinding, datatemplates และ MVVM ตัวเลือกนี้คล้ายกับวิธีออกแบบ WinForms แบบเก่าที่เรียบง่ายเชื่อถือได้

คอมโพสิต WPF

http://wpfcomposites.codeplex.com/

ในที่นี้ C-code-behind ที่รัดกุมสำหรับ WPF ถูกสร้างขึ้นโดยการวางเมทริกซ์แบบง่าย ๆ ไว้ด้านบนของ UI ผ่านคอมโพสิตแบบอิงกริด หาก XAML UI ที่ทันสมัยมีป้ายข้อความเพียงไม่กี่ตัวและกล่องรายการภาพถ่ายทำไมถึงไม่สามารถกำหนดได้ด้วยรหัสบรรทัดอย่างง่าย: grid.AddText (พิกัด guid, พิกัด x, y) หมายเหตุสิ่งนี้ไม่ได้อยู่บนผืนผ้าใบ แต่ยังอยู่ในคอนเทนเนอร์ WPF: กริดแท่นวางแผง ฯลฯ WPF มีประสิทธิภาพสูงมาก วิธีการนี้ใช้ประโยชน์จากสิ่งนี้

นักพัฒนามักไม่สนใจการฝึกอบรมและดัชนี เริ่มต้นด้วยระดับคอนเทนเนอร์แบบหยาบที่กำหนดโดย GUID ของ data transfer objects (DTOs) หรือ POCO จากนั้นชมคอนเทนเนอร์ที่บรรจุกุญแจเหล่านี้โดยเมทริกซ์ที่ละเอียดยิ่งขึ้นของแถวและคอลัมน์ที่มีศักยภาพภายใน?

โครงการ codeplex ข้างต้นแนะนำวิธีการนี้โดยเริ่มจากตัวควบคุมกล่องรายการ แต่กำลังขยายเพื่อครอบคลุมตัวควบคุมคอมโพสิต WPF ทั้งหมด ตัวอย่างเช่นแต่ละ listboxitem เป็นคอมโพสิตที่เพิ่มด้วย GUID (คอมโพสิตผูกแบบหนึ่งต่อหนึ่งกับคลาส) จากนั้นภายในรายการนี้จะมีกริดที่องค์ประกอบ UI ลูก (ลูกผูกคุณสมบัติแบบหนึ่งต่อหนึ่งกับคุณสมบัติ ในชั้นเรียน) อาจจะเพิ่มที่จะผ่านรหัสหลัง เด็ก ๆ อาจเป็นบล็อคข้อความหรือรูปภาพ

ความคิดคือการใช้ประโยชน์จากดัชนีและโครงสร้างองค์ประกอบ UI ที่กำหนดไว้อย่างดี (มันบังคับให้กล่องรายการแกนนำเสนอ PresentationFramework.Aero เป็นฐานในการเริ่มต้นจาก) แทนที่จะเป็นแผ่นข้อมูล วิธีการใหม่นี้มีจุดมุ่งหมาย จำกัด สิ่งที่สามารถทำได้ แต่การทำเช่นนั้นจะให้ผลตอบแทนที่รัดกุมและรัดกุมรหัส C # ที่อยู่เบื้องหลังที่ใช้งานง่าย ไม่จำเป็นต้องค้นหาโซลูชันเทมเพลตควบคุมสำหรับจัดแต่งทรงผมแถบเลื่อนหรือถ่วงโซลูชันด้วยเทมเพลตข้อมูลจำนวนมากสำหรับงานง่าย ๆ

MVVM ขึ้นอยู่กับกรอบ UI ที่ฉันใช้เป็นหลัก ดังนั้นด้วยสิ่งต่าง ๆ เช่น WPF หรือ Silverlight ที่มีกระบวนทัศน์ที่เชื่อมโยงกับ datacontext นั้น datacontext นั้นสามารถเรียกได้ว่าเป็น model view

ดังนั้นคำถามสำหรับฉันคือเมื่อคุณสร้างคลาสแยกไขมันขนาดใหญ่ซึ่งเป็นรูปแบบมุมมองสำหรับตัวควบคุม / หน้าต่าง / แอปพลิเคชันนี้และเมื่อใดที่คุณสามารถออกไปด้วยการใช้วัตถุที่สร้างขึ้นแล้ว

ดังนั้นเราจึงมีคำถามคลาสสิกเกี่ยวกับการเพิ่มเลเยอร์ของนามธรรม VM กำลังจะเพิ่มน้ำหนักความเฉื่อยและโครงสร้างให้กับโครงการ มันจะทำให้ง่ายต่อการต่อเติม แต่จะเปลี่ยนและสร้างได้ยากขึ้น ไม่มีสิ่งเหล่านั้นที่วัดได้อย่างง่ายดาย

สำหรับคำตอบที่ถูก MVVM ไม่เหมาะสำหรับแอพบรรทัดคำสั่งหรือบริการบนเว็บ :)