MVVM - dobra praktyka z ilością klas modelu widoku

Witam.
Mam pytanie odnośnie dobrych praktyk w tworzeniu aplikacji WPF z wzorcem MVVM. Otóż moje pytanie brzmi ile klas modelu widoku tworzyć do danego widoku. Czy kierować się zasadami:

1. Jeden widok - jedna klasa widoku modelu.
2. Jedna klasa widoku modelu - wiele widoków powiązanych ze sobą pod względem logicznym. Przykładowo osobne widoki dla dodawania, edycji, przeglądania danych.
3. Jeden widok modelu dla całego modułu - przykładowo mamy jakiś moduł pracowników z podglądem godzin pracy, delegacji, samochodów służbowych itp. Z warstwy modelu dziedziny mamy kilka klas wykorzystywanych w ramach modułu, ale jedną klasę widoku modelu.

Jakie podejście powinno się stosować.

Ad. 1
To wszystko zależy od tego jak bardzo złożony jest widok. Kiedy masz tam bardzo dużo bindowania to możesz podzielić bindowanie widoku na kilka viewmodeli i zadbać o komunikację pomiędzy nimi.

Ad. 2
Można ale przy większym projekcie zrobi Ci się bałagan. Jeżeli decydujesz się na takie podejście to trzeba bardzo pilnować porządku w VM tj: tego w jakim trybie znajduje się teraz klasa. Czy user dodaje coś czy edytuje. Może się to trochę pomieszać. Jedna klasa - jedna odpowiedzialność.

Ad. 3
Tak jak w punkcie pierwszym, jeżeli moduł jest nieduży i viewmodel nie zajmie Ci 3000 linijek, które przeznaczysz na same tylko bindowanie danych to pewnie, że tak można zrobić.

Nie ma uniwersalnego rozwiązania. Wszystko zależy od złożoności widoku. Jak podzielisz jeden viewmodel na kilka klas pobindowanych do nazwijmy to "podgrup logicznych" w GUI to będziesz miał porządek przy bardzo dużej ilości kontrolek. W jednym module będziesz miał VM do danych osobowych, VM do danych dotyczących samochodu, VM do danych dotyczących metrażu mieszkania etc... etc... To wszystko będziesz mógł spiąć wspólnym VM albo przesyłać dane za pomocą jakiegoś kontenera IoC korzystając ze wspólnego dla tego modułu serwisu - do wyboru do koloru. Absolutnie nie jest regułą to, że robisz jeden VM dla jednego widoku.

Do budowy View i View-Modelu podchodzę jak do budowy modelu. Wiele "małych" widoków, każdy posiadający swój własny ViewModel. Plus jest taki, że view i view-modele można łatwo utrzymywać. Nie ma problemu z podmianą lub zmianą części widoku, nie robi się spagetti. Oczywiście takie podejście wymaga napisania większej ilości kodu oraz View-Modeli spinających mniejsze View-Modele ale do tej pory nie wymyśliłem niczego lepszego.