synchronisation d'écran - Événement Agrégateur VS Mise en cache ViewModel Références

Question

je l'ai fait des devoirs et ne pouvait pas trouver un article sur les meilleures pratiques sur l'utilisation de chaque méthode ..

juste pour clarifier: Lorsque vous utilisez le modèle d'agrégation d'événements: chaque écran possède sa propre référence d'un viewmodel, le viewmodel publie des modifications en utilisant l'eventaggregator, que les observateurs utilisent ensuite pour synchroniser leur état.

Mise en cache ViewModels: chaque écran a la sauvegarde referece du viewmodel, les contrôles qui sont liés aux propriétés du modèle de vue sont synchronzied, parce que chaque écran dans l'application a la même référence de la viewmodel (obtenu depuis un cache), tous les écrans sont synchronisés grâce à la liaison de données.

quand utiliser chaque approche? Quels sont les avantages de l'utilisation de chacun d'eux?

Answer 1

Eh bien, comme je le vois, l'approche agrégateur d'événements est plus évolutive et permet une conception plus découplée. L'approche de VM unique (ou de mise en cache de plusieurs machines virtuelles) est bonne lorsque l'évolutivité n'est pas un problème, car la machine virtuelle peut atteindre des proportions monstrueuses à mesure que de plus en plus de vues sont ajoutées. En résumé, l'approche d'agrégation d'événements est l'approche «correcte» pour les systèmes conçus pour durer, mais vous pouvez utiliser l'approche la plus simple si vous construisez un outil interne pour un usage et une durée de vie spécifiques.

Answer 2

merci pour la réponse rapide! ce que vous dites n'est vrai que si la même classe VM est utilisée pour plusieurs écrans, et satisfait le contrat pour chacun d'entre eux (dans ce cas, la VM peut contenir un champ redondant, qui ne sont pas utilisés dans certains écrans il).

mais cette situation est facilement fixée lorsque vous utilisez la composition, en utilisant une approche plus ... grain fin

BTW, je suis d'accord que aggrégateur d'événement est plus découplées ... toute autre considération?

Answer 3

Une autre option qui fonctionne bien pour les données communes consiste à lier directement à une seule classe Observer qui expose les propriétés nécessaires plutôt que d'avoir des propriétés dupliquées dans plusieurs modèles de vue qui doivent être synchronisés. Alors que l'utilisation d'un observateur est plus couplée que l'abonnement/publication à l'agrégateur d'événements, lorsque les interfaces observateur sont injectées à l'aide d'un conteneur IOC, le couplage reste relativement libre et il est très facile de déterminer quels viewmodels dépendent des observateurs .