Que doit savoir une vue sur le modèle?

Je construis une application en python avec un wrapper python pour WPF et avec le support DAG. Je suis actuellement à un point où je dois décider d'une manière cohérente d'interagir entre les données et la vue.

À ma connaissance, il existe actuellement deux solutions évidentes.

Le premier est similaire à la structure des applications Android. Vous avez un contrôleur qui définit / remplit la vue. Le contrôleur possède donc la vue et ne pousse que les données primitives qui seront affichées. La vue est juste une couche stupide et n'a aucune idée de ce qui se passe et d'où proviennent ces données. Et puis, si l'utilisateur interagit avec la vue, il enverra des rappels au contrôleur (s'il s'est enregistré).

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)

La seconde consiste à passer un (référence de) modèle à la vue et à laisser la vue récupérer et mettre à jour les données. La vue contient maintenant le modèle et peut donc le mettre à jour sans aucun rappel supplémentaire au contrôleur.

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)

Donc, je suppose que ce que je demande, est-ce que je devrais passer les données très primitives et garder la vue aussi générique que possible, puis travailler avec les rappels et faire les spécificités de l'entreprise dans le contrôleur.

Ou dois-je passer tout le modèle à la vue et laisser la vue mettre à jour le modèle directement. Cela signifie qu'il y aura moins de code à taper.

PS. Ne jugez pas le code - c'est juste pour la visualisation.

ÉDITER:

Également à ajouter - cette application sera écrite en python qui supporte le typage duck. Cela signifie qu'avec la deuxième approche, la vue est toujours réutilisable tant que le modèle répond à l'interface requise.

La seule "logique" qu'une vue doit contenir doit être le code responsable de la modification de l'état visible de l'interface graphique par l'utilisateur. Tout code qui manipule des données ou calcule une valeur doit être géré ailleurs.

Votre vue doit savoir à quoi ressemble le modèle, mais doit ignorer le comportement associé à tout ce que le modèle expose.

La transmission de types de données simples à votre vue la rend responsable de la manipulation de l'interface graphique et du stockage de l'état de la vue, ce qui peut facilement devenir difficile à gérer.

Vous devez passer le modèle directement à la vue si le modèle est conçu pour être manipulé par la vue. Si votre modèle est le même que celui utilisé par votre mécanisme de stockage de données, cela peut entraîner des problèmes sur le long terme si votre représentation interne et votre représentation de vue divergent (comme c'est souvent le cas).

Fondamentalement, vous devez simplement avoir une vue, un modèle de vue, un modèle de données et quelque chose pour gérer la logique métier. Ensuite, toutes vos préoccupations sont facilement séparées, il vous suffit de les coller ensemble.

Il s'agit d'une réponse quelque peu généralisée, mais la vue de l'OMI devrait faire le moins de travail possible (par exemple, valider les entrées des utilisateurs).

De cette façon, vous pouvez vous attendre à ce que toute votre logique soit dans le contrôleur. Cela rend beaucoup plus facile à maintenir sur la route, le principe de responsabilité unique, et tout ça.