Est-ce la même chose que le «ViewModel» du modèle de conception Model-View-ViewModel (MVVM)
Nan.
Ce serait ceci :
Cela a des cycles. L'oncle Bob a soigneusement évité les cycles .
Au lieu de cela, vous avez ceci:
Qui n'a certainement pas de cycles. Mais vous vous demandez comment la vue connaît une mise à jour. Nous y reviendrons dans un instant.
ou s'agit-il d'un simple objet de transfert de données (DTO)?
Pour citer Bob de la page précédente:
Vous pouvez utiliser des structures de base ou de simples objets de transfert de données si vous le souhaitez. Vous pouvez également l'intégrer dans une table de hachage ou la construire dans un objet.
Architecture propre p207
Alors, bien sûr, si vous le souhaitez.
Mais je soupçonne fortement ce qui vous dérange vraiment, c'est ceci :
Ce joli petit abus d'UML contraste la direction de la dépendance du code source avec la direction du flux de contrôle. C'est là que se trouve la réponse à votre question.
Dans une relation d'utilisation:
le flux de contrôle va dans le même sens que la dépendance du code source.
Dans une relation de mise en œuvre:
le flux de contrôle va généralement dans la direction opposée à la dépendance du code source.
Ce qui signifie que vous regardez vraiment ceci:
Vous devriez être en mesure de voir que le flux de contrôle ne va jamais passer du présentateur à la vue.
Comment est-ce possible? Qu'est-ce que ça veut dire?
Cela signifie que la vue a son propre thread (ce qui n'est pas si inhabituel) ou (comme le souligne @Euphoric) que le flux de contrôle entre dans la vue à partir d'autre chose non représenté ici.
S'il s'agit du même thread, la vue saura quand le modèle de vue sera prêt à être lu. Mais si c'est le cas et que la vue est une interface graphique, il sera difficile de repeindre l'écran lorsque l'utilisateur le déplace pendant qu'il attend la base de données.
Si la vue a son propre thread, elle a son propre flux de contrôle. Cela signifie que pour l'implémenter, la vue devra interroger le modèle de vue pour remarquer les changements.
Puisque le présentateur ne sait pas que la vue existe et que la vue ne sait pas que le présentateur existe, ils ne peuvent pas s’appeler du tout. Ils ne peuvent pas se lancer des événements. Tout ce qui peut arriver, c'est que le présentateur écrira sur le modèle de vue et que la vue lira le modèle de vue. Chaque fois que ça en a envie.
Selon ce diagramme, la seule chose que le partage View et Presenter est la connaissance du View-Model. Et ce n'est qu'une structure de données. Ne vous attendez donc pas à ce qu'il ait un comportement.
Cela peut sembler impossible, mais il peut être fait fonctionner même si le View-Model est complexe. Un petit champ mis à jour est tout ce que la vue devrait interroger pour détecter un changement.
Maintenant, bien sûr, vous pouvez insister pour utiliser le modèle d'observateur, ou demander à quelque chose de structuré de vous cacher ce problème, mais veuillez comprendre que vous n'êtes pas obligé de le faire.
Voici un peu de plaisir que j'ai eu pour illustrer le flux de contrôle:
Notez que chaque fois que vous voyez le flux aller à l'encontre des directions que j'ai définies précédemment, ce que vous voyez est un retour d'appel. Cette astuce ne nous aidera pas à accéder à la vue. Eh bien, sauf si nous revenons d'abord à ce qu'on appelle le contrôleur. Ou vous pouvez simplement changer la conception pour pouvoir accéder à la vue. Cela corrige également ce qui ressemble au début d'un problème de yo-yo avec Data Access et son interface.
La seule autre chose à apprendre ici, en plus de cela, est que l'interacteur de cas d'utilisation peut à peu près appeler les choses dans l'ordre qu'il veut tant qu'il appelle le présentateur en dernier.