Jak zachować logikę widoku z modelu i logiki biznesowej z modelu widoku w MVVM?

Question

Nie mogę do końca dowiedzieć się, jak uzyskać model widoku, który ma być powiadamiany o zmianach w modelu, bez dodawania zestawu konkretnych elementów interfejsu, takich jak INotifyProperyChanged i INotifyCollectionChanged w moim modelu lub tworzenia ton różnych zdarzeń i robienia wielu rzeczy czują, że są specyficzne dla interfejsu użytkownika i powinny pozostać poza modelem.

W przeciwnym razie musiałbym skopiować całą logikę biznesową w modelu widoku, aby upewnić się, że wszystko jest aktualne, a następnie jaki jest sens posiadania tego modelu?

Jedną z trudnych, które mam w moim modelu, jest właściwość klasy "Kategoria". Możesz myśleć o nim jak o strukturze drzewa, a właściwość to potomkowie węzłów liści. W modelu, którego własność jest generowana w locie rekursywnie przez wszystkie jej dzieci, co jest w porządku i dobrze. Model widoku musi jednak wiązać się z tą właściwością i musi wiedzieć, kiedy się zmienia. Czy powinienem zmienić model, aby dostosować go do modelu widoku? Jeśli to zrobię, model widoku tak naprawdę nie zrobi nic w tym momencie, model podnosi wszystkie niezbędne powiadomienia o zmianach, a widok może po prostu wiązać się bezpośrednio z modelem. Również, jeśli model był czymś, czego nie miałem źródła, w jaki sposób obejść to?

Answer 1

Nie zgadzam się, że INotifyPropertyChanged i INotifyCollectionChanged są specyficzne dla interfejsu użytkownika. Znajdują się one w przestrzeniach nazw i złożeniach, które nie są powiązane z żadnym stosem interfejsu użytkownika. Z tego powodu zazwyczaj umieszczam tego rodzaju zachowanie w systemie tak niskie, jak to tylko możliwe (zazwyczaj warstwa danych).

Jeśli jest jakiś powód, dla którego nie chcesz umieścić go na tym poziomie, w porządku. Możesz umieścić go na wyższym poziomie, takim jak warstwa usługi lub warstwy interfejsu użytkownika. Należy jednak upewnić się, że wszystkie zmiany w strukturach danych występują również w tej warstwie.