Karmaşık MVVM ile ilgili yardım (çoklu görünümler)

Aşağıdaki senaryo için görünüm modelleri oluşturma konusunda yardıma ihtiyacım var:

Derin, hiyerarşik veriler
Aynı veri kümesi için birden çok görünüm
Her görünüm, etkin seçime dayalı, dinamik olarak değişen tek bir görünümdür
Bir özelliğin değerine bağlı olarak, sekme denetiminde farklı sekme türlerini görüntüleme

resim açıklamasını buraya girin

Sorularım:

Her görünüm (VM1, VM2, vb.) İçin bir görünüm modeli sunumu oluşturmalı mıyım?

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?

İşte tek bir görünüm örneği

Şekil 1: Aktif odaya göre güncellenen çoklu görünümler. Uyarı Sekmesi denetimi

resim açıklamasını buraya girin

Şekil 2: Farklı aktif oda. Birden çok görünüm güncellendi. Sekme denetim öğeleri nesnenin özelliğine göre değişti.

resim açıklamasını buraya girin

Şekil 3: Farklı seçim tipi. Tüm görünüm değişiklikleri

resim açıklamasını buraya girin

wpf mvvm

— jayars
kaynak

btw muli görüşü nedir? typo?

— Mart'ta JensG

"Muli görünümü" bir yazım hatası oldu. Aynı model / görünüm modeli için farklı görüşler demek istedim. Benim sorum, her görünüm için tüm model hiyerarşisini yeniden biçimlendirmem / sarmam gerekiyordu, bu yüzden her görünüm modeli yalnızca bireysel görünümün gereksinimlerini içeriyor mu? Yoksa tüm görünümlerden özellikler içeren tek bir görünüm modeli hiyerarşisi mi oluşturmalıyım? Bu soruyu yayınladığımdan beri, ikisinin artılarını / eksilerini zor yolu bulabilecek kadar şanslıydım. Gelecekte bu iş parçacığı, işler telaşlı olmadığında, deneyimimin tam teşhisi ile güncellenecektir.

— jayars

Bir tasarım kuralının önce genel şeyleri göstermek, sonra ayrıntılara inmek olduğunu unutmayın. size hafif bir görünüm bırakır ve kullanıcı daha derine inerse yeni görünümler görünür. Bu yüzden kendi görünüm modeli ile küçük görünümleri kullanın. bu makaleye göz

— atın

@jsjslim "Tüm hiyerarşileri senkronize tut" i okuduğumda titredi. Çoklu görüşe geçtiğinizden şüpheleniyorum ve pişman olduğunuzdan şüpheleniyorum (ama daha önce yanılmışım). Aynı soruyu sorabilen diğer okurlar uğruna, en azından bize hızlı bir cevap verebilir misiniz?

— Guy Schalnat

@ guy-schalnat Çoklu görünüm bir gereklilikti. Benim sorunum görünüm modellerinin nasıl oluşturulacağını anlamaya çalışmaktı. Proje hala devam ediyor ve tam bir analiz hazırlamak için zaman bulamıyorum. Ancak özet olarak: Model yapısını görmezden gelmeliydim ve görüşlere odaklanmalıydım. Karşılaştığım karmaşıklık kendine empoze edildi: WPF'nin veri bağlamasını çok kötü kullanmak istedim, düzeltildim. Sonunda yaptığım iyi, eski "kopyala / yapıştır / refactor" oldu. Ortaya çıkan son tasarım hafifti (az tekrar) ve daha da önemlisi çalıştı. Gelecekte tam bir analiz yazacaktır.

— jayars

Yanıtlar:

Soruyu cevaplamak için, Evet, her görünümün kendi Görüntüleme Modeli olmalıdır. Ancak tüm hiyerarşiyi modellemeye gerek yoktur. Sadece görünümün ihtiyacı.

MVVM ile ilgili en fazla çevrimiçi kaynakla yaşadığım sorun:

Çoğu örnekte Görünüm, Modelin neredeyse 1'e 1 eşleşmesidir. Ama aynı Modelin farklı yönleri için farklı görüşlerin olduğu senaryomda, kendimi iki seçenek arasında sıkışmış buluyorum:

Diğer tüm görünüm modelleri tarafından kullanılan bir monolitik görünüm modeli

Veya her görünüm için bir görünüm modeli

Ama ikisi de ideal değil.

Model odaklı Görüntüleme Modeli (MVM), kod çoğaltmada düşük olsa da, sürdürülmesi gereken bir kabus

Görünüm Odaklı Görünüm Modeli (VVM) her görünüm için son derece özel sınıflar üretir, ancak kopyalar içerir.

Sonunda, Görüntüleme başına bir VM'ye sahip olmanın ve kodlamanın daha kolay olduğuna karar verdim, bu yüzden VVM yaklaşımı ile gittim.

Kod çalıştıktan sonra, tüm ortak özellikleri ve işlemleri geçerli, son haline getirmeye başladım:

Bu son formda, ortak görünüm model sınıfı her bir VVM'de oluşturulur.

Tabii ki, hala neyin ortak / özel olarak kabul edildiğine karar vermeliyim. Bir görünüm eklendiğinde / birleştirildiğinde / silindiğinde bu denge değişir.

Ancak bununla ilgili güzel olan şey, artık üyeleri ortaktan VVM'ye yukarı / aşağı doğru itebiliyorum ve bunun tersi de kolay.

Nesneleri senkronize tutma hakkında kısa bir not:

Ortak Görüş Modeline sahip olmak bunların çoğunu halleder. Her VVM'nin aynı Ortak Görünüm Modeline bir referansı olabilir.

Ayrıca, basit geri çağrı yöntemleriyle başlama eğilimindeyim ve birden fazla dinleyiciye ihtiyaç duyulduğunda olay / gözlemciye dönüşüyorum.

Ve gerçekten karmaşık olaylar için (yani, beklenmedik basamaklı güncellemeler), bir Arabulucu kullanmaya geçirdim.

Bir çocuğun ebeveynine geri başvurusu olduğu koddan uzak durmuyorum. Kodun çalışmasını sağlamak için her şey.

Ve yeniden düzenleme fırsatı doğarsa, ben de alırdım.

Aldığım dersler:

Çirkin / Çalışma kodu> Güzel / Çalışmayan kod
Birden fazla küçük sınıfı birleştirmek, büyük bir sınıfı ayırmaktan daha kolaydır

— jayars
kaynak

Keşke bunu iki kez değerlendirebilseydim. Bu gördüğüm seçeneklerin en açık açıklamalarından biri.

— CleverPatrick

Maketlerinize baktığımda kesinlikle ViewModels ve birçok küçük Views hiyerarşisi oluşturmanızı tavsiye ederim. Ve muhtemelen orijinal hiyerarşinin bir kısmını modellemeniz gerekecek.

Olayları ViewModels arasında senkronize tutmak için olaylardan birini kullanın veya ViewModels arasında birbirinizle ilgili özelliklere sahip olun. Views ve ViewModels arasındaki senkronizasyon standart bildirim özellikleri olmalıdır.

— öforik
kaynak