J'ai un 1) philosophiquement, est-ce une bonne pratique d'utiliser un modèle singleton pour cette viewModel, car il est répandu sur toute l'application et il est utilisé à de nombreux endroits.
2) N'est-ce pas un problème pour ViewModel (et associé Merci! ViewModel pour la manipulation de l'ENUMS (peu d'entités dans la structure d'entité).
objetContext ) pour vivre très longtemps?
5 Réponses :
Cela devrait probablement être divisé en deux questions distinctes, mais je vais prendre un coup de poignard à la fois:
non. Il n'y a aucune raison d'être un point de vue devrait être un singleton. Vous voulez réellement plusieurs cas (car chacun allait varier) plutôt qu'une seule instance qui vit pour la course de l'application. Juste parce qu'un objet est répandu et est utilisé fréquemment, cela ne fait pas un bon candidat à un singleton ... Cela signifie simplement que c'est un bon objet.
ViewModels ne devrait pas avoir une très longue vie (une autre raison pour laquelle vous ne voulez pas de singleton). Dans MVVM, la durée de vie d'une vue de vue donnée serait tant que l'utilisateur dispose de la fenêtre ouverte et termine leurs modifications.
Salut Justin, merci. Une question ... J'ai 3-4 Windows et leur contenu doit être synchronisé. Cela nécessite des efforts pour le faire. Je pensais que si j'avais un point de vue comme un singleton, ce modèle rebindrait automatiquement quelques datacontexts ...
Un singleton serait partagé non seulement par toutes les "Windows" mais également par tous les utilisateurs - voulez-vous vraiment cela?
Il est toujours possible d'utiliser le même exemple dans ces quatre fenêtres, vous n'avez pas besoin d'un singleton pour cela.
Vous avez besoin d'une instance session scopée.
Cela dépend de votre application, comment est-il structuré? Utilisez-vous plusieurs modules, comme dans Prism? Utilisez-vous l'injection? Comment créez-vous les vues et les menuisages? Normalement, vous pouvez créer une instance de votre viewModel et définir simplement le DataContext de chaque fenêtre dans cette instance. Mais vous pouvez créer une menace de vision différente pour chaque fenêtre (Window1ViewModel, Window2ViewModel) et chacune d'elles a une propriété qui pointe vers le même exemple commun de CommonViewModel. Il y a beaucoup de possibilités.
Les objets vivent uniquement sur la pile aussi longtemps que les collectionneurs à déchets les jugent nécessaire. Philosophiquement non, ce n'est pas une bonne idée d'utiliser Singleton car il brise l'encapsulation. Voir l'article: singleton antidiaptern
mille excuses, tas. Stackoverflow.com/ Questions / 2129044 / ...
Comme Justin mentionné, il semble peu probable que vous auriez besoin de vos images de vue pour suivre le modèle singleton. Cependant, comme vous l'avez mentionné, voir les modèles sont utilisés dans tout le système. Envisagez de tirer des fonctionnalités communes dans les classes de base (si vous aimez l'héritage) et / ou tirez des composants réutilisables dans des objets pour profiter de la composition.
Un moyen facile de commencer C'est toutes les lignes de la vue de Josh Smith et une utilisation d'une vue de vue typique de InotifyPropertychanged.
Donner ce code un look ici: http://mvvmfoundation.codeplex.com/
1) Ne le faites pas. Voir MVVM ViewModels Singleton 2) Je ne pense pas que ce soit une bonne idée d'avoir un point de vue couplé à un contexte d'objet. Il ne devrait s'agir que d'une vue de vue, fournissant des données à une vue; mais pas étroitement couplé à une technologie de persistance de données. Au lieu de cela, injecter des services qui s'occupent de cela, de sorte que vous pouvez les moquer.
Avoir un site de vue singleton est entièrement valable dans des cas spécifiques. Un exemple que j'ai utilisé plusieurs fois est un paramètreviewModel. Ce qui doit être accédé à l'échelle mondiale par plusieurs systèmes de l'application. Mon modèle de paramètres sur la création charge les paramètres d'un fichier, la viewmodel me permet de se lier à modifier ces paramètres. Le singleton me permet d'accéder globalement à ces paramètres où j'ai besoin au lieu de les transmettre en tant que paramètres.
entièrement valide, dans ce cas.
Imo, dans votre description, on dirait que le modèle est le singleton, pas le point de vue. Normalement, le modèle de vue est la colle entre une instance de vue et l'instance de modèle. Un modèle d'affichage ne stockerait normalement pas l'état caché à l'extérieur de la vue, il ne doit pas contrôler la fonctionnalité.