Bantuan dengan MVVM kompleks (banyak tampilan)

Saya perlu bantuan membuat model tampilan untuk skenario berikut:

Data yang mendalam dan hierarkis
Banyak tampilan untuk kumpulan data yang sama
Setiap tampilan adalah tampilan tunggal, yang berubah secara dinamis, berdasarkan pilihan aktif
Bergantung pada nilai properti, tampilkan berbagai jenis tab dalam kontrol tab

masukkan deskripsi gambar di sini

Pertanyaan saya:

Haruskah saya membuat representasi model tampilan untuk setiap tampilan (VM1, VM2, dll)?

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?

Berikut adalah contoh tampilan tunggal

Gambar 1: Beberapa tampilan diperbarui berdasarkan ruang aktif. Perhatikan kontrol Tab

masukkan deskripsi gambar di sini

Gambar 2: Kamar aktif berbeda. Beberapa tampilan diperbarui. Item kontrol tab berubah berdasarkan properti objek.

masukkan deskripsi gambar di sini

Gambar 3: Jenis seleksi yang berbeda. Seluruh tampilan berubah

masukkan deskripsi gambar di sini

wpf mvvm

— jayars
sumber

btw apa itu muli view? salah ketik?

— JensG

"Muli view" adalah salah ketik. Maksud saya berbeda pandangan untuk model / model tampilan yang sama. Pertanyaan saya adalah, apakah saya harus merombak / membungkus seluruh hierarki model untuk setiap tampilan, sehingga setiap model tampilan hanya berisi apa yang dibutuhkan tampilan individual? Atau haruskah saya membuat hierarki model tampilan tunggal yang berisi properti dari semua tampilan? Karena saya memposting pertanyaan ini, saya (tidak) cukup beruntung untuk mengetahui pro / kontra dari keduanya, cara yang sulit. Akan memperbarui utas ini di masa mendatang dengan diagnosis lengkap dari pengalaman saya, setelah semuanya tidak sibuk.

— jayars

Ingat aturan desain adalah untuk menunjukkan hal-hal umum terlebih dahulu kemudian masuk ke detail. itu akan meninggalkan Anda dengan tampilan cahaya dan jika pengguna masuk lebih dalam maka tampilan baru akan muncul. jadi gunakan tampilan kecil dengan model view terpisah. periksa artikel ini desain antarmuka pengguna

— Csharls

@ jsjslim saya bergidik ketika membaca "jaga agar semua hierarki tetap sinkron". Saya curiga Anda menggunakan multi-view, dan saya curiga Anda menyesalinya (tapi sebelumnya saya salah). Demi pembaca lain yang mungkin memiliki pertanyaan yang sama, bisakah Anda setidaknya memberi kami jawaban cepat (ish)?

— Guy Schalnat

@ guy-schalnat Multi-view adalah persyaratan. Masalah saya adalah mencoba mencari cara membangun model tampilan. Proyek ini masih berlangsung, dan saya tidak dapat menemukan waktu untuk menulis analisis lengkap. Tetapi dalam ringkasan: Saya seharusnya mengabaikan struktur model, dan fokus pada pandangan. Kompleksitas yang saya temui itu dipaksakan sendiri: Saya ingin menggunakan pengikatan data WPF begitu buruk, saya terpaku. Apa yang saya lakukan pada akhirnya adalah "copy / paste / refactor" yang baik dan lama. Desain akhir yang muncul adalah ringan (pengulangan kecil), dan yang lebih penting, berhasil. Akan menulis analisis lengkap di masa depan.

— jayars

Jawaban:

Untuk menjawab pertanyaan, Ya, setiap tampilan harus memiliki Model Tampilan sendiri. Tetapi tidak perlu memodelkan seluruh hierarki. Hanya apa yang dibutuhkan tampilan.

Masalah yang saya miliki dengan sebagian besar sumber daya online tentang MVVM:

Dalam sebagian besar contoh, tampilan hampir 1-ke-1 pemetaan Model. Tetapi dalam skenario saya, di mana ada pandangan berbeda untuk berbagai sisi dari Model yang sama, saya menemukan diri saya terjebak di antara dua pilihan:

Satu model tampilan monolitik yang digunakan oleh semua model tampilan lainnya

Atau satu model tampilan untuk setiap tampilan

Namun keduanya tidak ideal.

Model-oriented View Model (MVM), meskipun duplikasi kode rendah, adalah mimpi buruk untuk dipertahankan

View-oriented View Model (VVM) menghasilkan kelas yang sangat terspesialisasi untuk setiap tampilan, tetapi berisi duplikat.

Pada akhirnya, saya memutuskan bahwa memiliki satu VM per Tampilan lebih mudah untuk dipelihara dan dikodekan, jadi saya menggunakan pendekatan VVM.

Setelah kode bekerja, saya mulai refactoring semua properti dan operasi umum ke dalam bentuk terakhirnya saat ini:

Dalam bentuk akhir ini, kelas model tampilan umum dikomposisikan ke dalam setiap VVM.

Tentu saja, saya masih harus memutuskan apa yang dianggap umum / terspesialisasi. Dan ketika tampilan ditambahkan / digabung / dihapus, saldo ini berubah.

Tapi yang menyenangkan tentang ini adalah, saya sekarang dapat mendorong anggota naik / turun dari yang umum ke VVM dan sebaliknya dengan mudah.

Dan catatan singkat tentang menjaga objek tetap sinkron:

Memiliki Model Pandangan Umum menangani sebagian besar dari ini. Setiap VVM dapat dengan mudah memiliki referensi ke Model Common View yang sama.

Saya juga cenderung memulai dengan metode panggilan balik sederhana, dan berkembang menjadi acara / pengamat jika kebutuhan akan banyak pendengar muncul.

Dan untuk acara yang sangat kompleks (yaitu, pembaruan cascading yang tidak terduga), saya akan beralih menggunakan Mediator.

Saya tidak menghindar dari kode di mana seorang anak memiliki referensi kembali ke orang tuanya. Apa pun agar kode berfungsi.

Dan jika kesempatan untuk refactor muncul, saya akan mengambilnya.

Pelajaran yang saya pelajari:

Jelek / Kode kerja> Cantik / Kode tidak bekerja
Lebih mudah untuk menggabungkan beberapa kelas kecil, daripada memecah kelas besar

— jayars
sumber

Saya berharap saya bisa membenarkan ini dua kali. Ini adalah salah satu penjelasan paling jelas dari opsi yang saya lihat.

— Manusia Cerdas

Melihat mockup Anda, saya pasti akan merekomendasikan membuat hierarki ViewModels dan banyak Tampilan kecil. Dan Anda kemungkinan besar harus memodelkan sedikit hirarki asli.

Untuk menyelaraskan berbagai hal di antara ViewModels, gunakan salah satu acara, atau miliki properti satu sama lain di antara ViewModels. Sinkronisasi antara Tampilan dan ViewModels harus menjadi properti pemberitahuan standar.

— Euforia
sumber