J'ai lu des informations sur Model View Controller, Model View Presenter, Model View ViewModel, et ainsi de suite, et en général, le concept sous-jacent semble assez simple à comprendre: garder les jolis visuels et les tripes scientifiques aussi séparés et ignorants les uns des autres que possible. Pas de logique de beurre d'arachide dans le chocolat design; cool, j'aime ça.
Le problème est que je suis toujours un peu flou quant à cette troisième partie ... celle qui n'est pas un modèle ou une vue. Tout le monde semble avoir sa propre idée de comment l'appeler, de ce qu'elle devrait faire, de ce qui est juste, de ce qui est tout simplement faux ... et je deviens fou en essayant de comprendre quand un présentateur devient un ViewModel et quand une vue ne devrait pas '' t faire cela parce que c'est le travail du présentateur et--
Je divague.
Plutôt que de demander à quelqu'un d'expliquer la différence entre eux - parce que cela a déjà été fait maintes et maintes fois (je sais; j'ai lu plus d'articles que je ne peux compter) - je serais curieux d'entendre les pensées d'un quelques programmeurs sur le modèle que j'ai bricolé moi-même.
Cela dit, que classeriez-vous cette conception comme, et peut-être plus important encore, voyez-vous quelque chose à ce sujet qui est évidemment nul? Bien sûr, j'aimerais entendre que je fais du bien si c'est vraiment un design solide, mais je préfère de loin recevoir des conseils solides sur les éloges.
Remarque: je vais utiliser "le pont" pour la troisième partie mystérieuse de Model-View-? pour éviter toute suggestion inconsciente de ce qu'elle "devrait" être.
Modèle
- Est l'autorité sur les données.
- Reçoit des informations sur les modifications demandées du pont.
- Contient et exécute toute la logique de la relation entre les données et les autres données.
Informe le pont lorsque les données changent (pour les données le pont a exprimé son intérêt).Modification du libellé: permet aux abonnés externes (dont il ne sait rien) de surveiller son état ou ses résultats de calcul.- N'a aucune connaissance de la vue.
Vue
- Soucie de fournir à l'utilisateur un moyen de visualiser et de manipuler les données.
- Reçoit des informations sur les mises à jour des données du pont.
- Contient et exécute toute la logique de présentation des données et des contrôles à l'utilisateur.
- Informe le pont lorsque l'utilisateur a effectué une action qui (éventuellement) affecte le modèle.
- Informe le pont des informations qui l'intéressent.
- N'a aucune connaissance du modèle.
Pont
- Est le coordinateur et le traducteur entre le modèle et la vue.
- Apporte toutes les modifications de mise en forme appropriées aux informations transmises entre le modèle et la vue.
- Conserve des informations sur "qui a besoin de savoir quoi".
- Connaît à la fois le modèle et la vue.
Notes complémentaires
- Dans les programmes plus compliqués, il est courant qu'il y ait plusieurs modèles. Dans cette situation, le pont assume généralement la tâche de coordination / traduction entre les multiples modèles et devient ainsi l'autorité sur laquelle les protocoles / API / modèles de conception doivent être construits. (Par exemple, si vous créez un programme de jeu de cartes et que vous souhaitez créer un autre modèle de mélange de cartes, vous devez utiliser le pont pour déterminer les fonctions requises pour une communication correcte avec le pont.)
- Dans les petits programmes simples avec une seule vue et un seul modèle, il est courant que le Bridge "assume" les fonctionnalités disponibles de chaque côté. Cependant, à mesure que les programmes deviennent plus complexes, il est recommandé que les vues et les modèles signalent leurs fonctionnalités au pont afin d'éviter les inefficacités et les hypothèses de bogue.
Je pense que ça couvre à peu près. Par tous les moyens, je me réjouis de toutes les questions que vous pourriez avoir sur la conception que j'ai tendance à utiliser, et j'encourage également toutes les suggestions.
Et comme toujours, merci pour votre temps.