Envoyé par
Arnaud F.
Juste pour qu'on soit bien d'accord, quand on parle de "binding", on parle bien de (sniiip du code):
C'est du binding manuel, ça. Windows Forms propose la classe Binding, utilisée comme suit :
this.textBoxTruc.DataBindings.Add(new Binding("Text", this.Presenter, "ClientName", true));
Ca fait partie de choses que le designer de winforms met en avant, et qui font que tu peux concevoir une bonne part d'une appli business classique (avec une grille qui chope des données d'un DB, par ex) rien qu'avec le designer, sans toucher au code.
Je vais pas te faire un cours sur la classe Binding, mais en gros ça synchronise une propriété graphique à une une propriété métier, avec une politique paramétrable de read / write entre UI et métier (dès modification, programmatiquement, ou à validation ; on peut aussi spécifier un formatage.)
Pour ton "Success" : perso, je considère qu'afficher un message à l'user n'est pas du ressort de la vue. Déjà parce que ça peut se faire au milieu d'un workflow (du style connecté ? oui => download ; non => demander confirmation à l'user ; si oui connection, sinon arrêt ; si ... tu vois le truc)
et donc j'ai une classe qui wrappe les messagebox, à laquelle les presenter ont accès.
Non, vraiment, la vue ne doit RIEN faire, à part wrapper son état, et faire du binding déclaratif. En WPF MVVM, elle ne contient aucun code, étant écrite en XAML. Par contre, elle configure déclarativement pas mal d'objets (commandes, bindings, ...)
Et quand on parle de la stupidité de la vue, là c'est un bel exemple, je ne fais rien de plus.
C'est déjà trop
la partie modèle ne doit pas être static
Ca ne remet pas en cause la réutisabilité de ton code, mais sa testabilité.
la partie modèle doit implémenter une interface de sorte que le presenter puisse recevoir les notifications du modele et le piloter au besoin.
Euh, non Faire du modèle une classe implémentant une interface, elle-même étant tout ce que le presenter connait, ca permet juste de limiter le couplage entre tes couches, avec tous les avantages associés (testabilité comme on a vu, mais aussi possibilité d'utiliser de l'injection de dépendances par exemple)
Partager