ความช่วยเหลือเกี่ยวกับ MVVM ที่ซับซ้อน (หลายมุมมอง)

ฉันต้องการความช่วยเหลือในการสร้างมุมมองแบบจำลองสำหรับสถานการณ์ต่อไปนี้:

1. ข้อมูลที่ลึกและเป็นลำดับชั้น
2. หลายมุมมองสำหรับชุดข้อมูลเดียวกัน
3. แต่ละมุมมองเป็นมุมมองเดียวที่เปลี่ยนแปลงได้แบบไดนามิกตามการเลือกที่แอ็คทีฟ
4. แสดงแท็บประเภทต่าง ๆ ในตัวควบคุมแท็บทั้งนี้ขึ้นอยู่กับมูลค่าของคุณสมบัติ

คำถามของฉัน:

ฉันควรสร้างการนำเสนอแบบจำลองมุมมองสำหรับแต่ละมุมมอง (VM1, VM2 ฯลฯ ) หรือไม่

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

นี่คือตัวอย่างของมุมมองเดียว

รูปที่ 1: มุมมองหลายรายการอัพเดทตามห้องที่ใช้งานอยู่ ประกาศการควบคุมแท็บ

รูปที่ 2: ห้องแอคทีฟที่แตกต่างกัน อัปเดตมุมมองหลายรายการแล้ว รายการควบคุมแท็บเปลี่ยนไปตามคุณสมบัติของวัตถุ

รูปที่ 3: ประเภทการเลือกที่แตกต่างกัน การเปลี่ยนแปลงมุมมองทั้งหมด

ในการตอบคำถามใช่แต่ละมุมมองควรมีรูปแบบมุมมองของตัวเอง แต่ไม่จำเป็นต้องทำแบบจำลองลำดับชั้นทั้งหมด เฉพาะมุมมองที่ต้องการ

ปัญหาที่ฉันมีกับทรัพยากรออนไลน์ส่วนใหญ่เกี่ยวกับ MVVM:

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

โมเดลมุมมองเสาหินหนึ่งที่ถูกใช้โดยโมเดลมุมมองอื่นทั้งหมด

หรือมุมมองหนึ่งแบบสำหรับแต่ละมุมมอง

แต่ทั้งคู่ก็ไม่เหมาะ

Model-oriented View Model (MVM) ในขณะที่การทำสำเนารหัสต่ำนั้นเป็นฝันร้ายที่ต้องรักษา

View-oriented View Model (VVM) สร้างคลาสที่มีความเชี่ยวชาญสูงสำหรับแต่ละมุมมอง แต่มีการทำซ้ำ

ในที่สุดฉันตัดสินใจว่าการมี VM ต่อหนึ่งมุมมองนั้นง่ายต่อการบำรุงรักษาและใช้รหัสดังนั้นฉันจึงใช้วิธี VVM

เมื่อรหัสทำงานฉันเริ่ม refactoring คุณสมบัติทั่วไปและการดำเนินงานทั้งหมดในรูปแบบปัจจุบันสุดท้าย:

ในรูปแบบสุดท้ายนี้คลาสโมเดลมุมมองทั่วไปถูกสร้างขึ้นในแต่ละ VVM

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

แต่สิ่งที่ดีเกี่ยวกับเรื่องนี้คือตอนนี้ฉันสามารถผลักดันสมาชิกขึ้น / ลงจาก VVM และกลับกันได้อย่างง่ายดาย

และบันทึกย่อเกี่ยวกับการรักษาวัตถุที่ซิงค์:

การมี Common View Model ดูแลส่วนใหญ่อยู่ VVM แต่ละตัวสามารถมีการอ้างอิงไปยัง Common View Model เดียวกันได้

ฉันมักจะเริ่มต้นด้วยวิธีการโทรกลับอย่างง่ายและพัฒนาเป็นเหตุการณ์ / ผู้สังเกตการณ์หากมีความต้องการผู้ฟังหลายคนเกิดขึ้น

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

ฉันไม่อายห่างจากรหัสที่เด็กมีการอ้างอิงกลับไปยังผู้ปกครอง อะไรก็ได้ที่ทำให้โค้ดทำงานได้

และถ้าโอกาสในการสร้างใหม่เกิดขึ้นฉันก็จะเอาไป

บทเรียนที่ฉันได้เรียนรู้:

1. รหัสน่าเกลียด / ใช้งานได้> รหัสสวยงาม / ไม่ทำงาน
2. เป็นการง่ายกว่าที่จะรวมคลาสเล็ก ๆ หลายคลาสเข้าด้วยกันเพื่อทำลายชั้นเรียนขนาดใหญ่

ดูที่การเยาะเย้ยของคุณฉันขอแนะนำให้สร้างลำดับชั้นของ ViewModels และมุมมองขนาดเล็กจำนวนมาก และคุณอาจจะต้องสร้างแบบจำลองลำดับชั้นเล็กน้อย

ในการซิงค์สิ่งต่าง ๆ ระหว่าง ViewModels ให้ใช้เหตุการณ์ใดเหตุการณ์หนึ่งหรือมีคุณสมบัติซึ่งกันและกันระหว่าง ViewModels การซิงค์ระหว่าง Views และ ViewModels ควรเป็นคุณสมบัติการแจ้งเตือนแบบมาตรฐาน