Ile powinien wiedzieć widok o modelu?

Buduję aplikację w Pythonie z otoki Pythona dla WPF i ze wsparciem DAG. Obecnie jestem w punkcie, w którym muszę zdecydować o spójnym sposobie interakcji między danymi a widokiem.

O ile wiem, istnieją obecnie dwa oczywiste rozwiązania.

Pierwszy jest podobny do struktury aplikacji Android. Masz kontroler, który ustawia / wypełnia widok. Tak więc kontroler jest właścicielem widoku i przekazuje tylko pierwotne dane, które zostaną wyświetlone. Widok jest tylko głupią warstwą i nie ma pojęcia, co się dzieje i skąd pochodzą te dane. A jeśli użytkownik wejdzie w interakcję z widokiem, wyśle ​​wywołania zwrotne do kontrolera (jeśli został zarejestrowany).

UserInfoController.py

userInfoView = UserInfoView()
userInfoView.onGenderChangedCallback = self.onGenderChangedCallback 
userInfoView.setUserGenderValue(user.getGender())

UserInfoView.py

def setUserGenderValue(self, gender):
    self.userGender = gender

def getView(self):
    return ui.Label(self.userGender, onEditCallback=self.onGenderChangedCallback)

Drugi polega na przekazaniu do modelu (referencji) modelu i umożliwieniu mu pobrania i aktualizacji danych. Widok zawiera teraz model i dlatego może go aktualizować bez żadnych dodatkowych wywołań zwrotnych do kontrolera.

UserInfoViewModel.py

self.gender = 'Male'

UserInfoView.py

def getView(self):
    return ui.Label(self.ViewModel().getGender(), onEdited=self.genderEdited)

def genderEdited(self, newValue):
    self.ViewModel().setGender(newValue)

Myślę, że pytam o to, czy powinienem przekazać bardzo prymitywne dane i zachować widok tak ogólny, jak to możliwe, a następnie pracować z wywołaniami zwrotnymi i wykonywać specyfikacje biznesowe w kontrolerze.

A może powinienem przekazać cały model do widoku i pozwolić widokowi na bezpośrednią aktualizację modelu. Oznacza to, że będzie mniej kodu do wpisania.

PS. Nie oceniaj kodu - to tylko wizualizacja.

EDYTOWAĆ:

Również dodać - ta aplikacja zostanie napisana w języku python, który obsługuje przechwytywanie. Oznacza to, że przy drugim podejściu widok jest nadal wielokrotnego użytku, o ile model spełnia wymagany interfejs.

Jedyną „logiką”, jaką powinien zawierać widok, powinien być kod odpowiedzialny za zmianę widocznego stanu GUI na użytkownika. Każdy kod, który manipuluje danymi lub oblicza wartość, powinien być obsługiwany w innym miejscu.

Twój widok powinien wiedzieć, jak wygląda model, ale powinien być nieświadomy zachowania związanego z czymkolwiek, co model ujawnia.

Przekazywanie prostych typów danych do widoku powoduje, że jest on odpowiedzialny zarówno za manipulowanie graficznym interfejsem użytkownika, jak i za przechowywanie stanu widoku, co może łatwo stać się niewygodne.

Powinieneś przekazać model bezpośrednio do widoku, jeśli model jest zbudowany do manipulowania przez widok. Jeśli Twój model jest taki sam, jak używany przez mechanizm przechowywania danych, może to powodować problemy w przyszłości, jeśli Twoja wewnętrzna reprezentacja i reprezentacja widoku różnią się (jak to często bywa).

Zasadniczo powinieneś mieć widok, model widoku, model danych i coś do obsługi logiki biznesowej. Następnie wszystkie obawy można łatwo oddzielić, wystarczy je skleić.

Jest to dość ogólna odpowiedź, ale widok IMO powinien wykonać jak najmniej pracy (np. Zweryfikować dane wejściowe użytkownika).

W ten sposób możesz oczekiwać, że cała logika będzie w kontrolerze. To znacznie ułatwia utrzymanie drogi, zasady pojedynczej odpowiedzialności i tak dalej.