Voici un exemple de cas pour élaborer:
Je crée de manière dynamique un graphe à barres simple à l'aide d'un articleControl à mon avis et liant les éléments à une collection de moteurs BarviewModels (chacun contenant une valeur de valeur) dans mon barGraphViewModel.
Chaque barre doit avoir une couleur différente. Les couleurs doivent être choisies parmi une collection par ex. La collection elle-même est constante mais le nombre de barres dépendra des circonstances. Une solution simple serait Pour créer une simple barViewModel, comme si: (J'ai laissé la propriété de la propriété modifiée et la mise en œuvre de la validation pour la brièveté) Maintenant, je pourrais simplement créer une barreViewModels de Mon barGraphViewModel pour chaque pourcentage et passe dans la brosse colorée appropriée créée à partir de ma collection de couleurs. puis dans XAML, je créerais une plaque d'identité simple qui se liera à ces propriétés. seulement maintenant, Comme il contient une propriété de type SolidColorBrush, ma viewModel dépend du cadre de présentation et devrais-je vouloir l'utiliser dans un autre environnement qu'il devra être changé. est-ce donc cassant les meilleures pratiques MVVM, ou C'est acceptable (tu dois dessiner la ligne quelque part ou que les choses deviennent trop compliquées) Je voulais juste voir ce que les autres pensent de cela et s'il y a d'autres solutions qui gardent T Il ignore totalement la couche de présentation sans devenir trop compliqué.
Je pouvais imaginer que les évaluateurs pouvaient aider? {color1, couleur2, ..}
3 Réponses :
théoriquement, la situation que vous avez décrite est contre les meilleures pratiques en MVVM. Mais il y a une solution simple pour nettoyer votre modèle de vue. Vous devez créer votre propre type pour représenter la couleur dans la vue du modèle - il peut s'agir de la chaîne, de l'int ou de l'énum. Ensuite, vous pouvez écrire une valeur de valeur personnalisée (implémentation d'IValueconverter) pour convertir le type de couleur du modèle de vue dans la représentation de couleur dépendante de la présentation. Le convertisseur doit être utilisé avec une expression délimitée. Exemple sur la conversion de valeurs limitées est ici .
Je vois non les raisons techniques Pourquoi votre VM ci-dessus est mauvais, mais utiliserait personnellement une brosse Cependant, il y a d'autres raisons pour lesquelles cela pourrait être une mauvaise idée. Votre modèle de vue sera-t-il probablement utilisé dans un environnement non-WPF? Si tel est le cas, vous voudrez une abstraction qui puisse ensuite être traduite dans une construction spécifique à la plate-forme, avec la brosse Avez-vous des concepteurs de votre équipe? Si tel est le cas, l'utilisation d'un brosse dans votre VM peut inhiber leur capacité à personnaliser l'interface utilisateur. Votre cas spécifique ci-dessus peut être une entreprise aberrante, mais en général, la collaboration de concepteur et de développeur bénéficie de la VM Expose State, et le rendu de vision de l'État. Dès que le VM dicte l'apparence visuelle de toute capacité, vous avez limité les décisions que vos concepteurs peuvent faire.
Dans mon expérience, la deuxième raison est beaucoup plus commune de ne pas inclure des constructions spécifiques à l'UI dans votre VM. plutôt qu'une sous-classe spécifique. Je ne crois pas que cela brise les meilleures pratiques MVVM, car votre VM est un modèle de votre vue. Il ne faut pas nécessairement être agnostique de la technologie sur laquelle votre vision est construite.
de WPF étant un tel exemple. Et les convertisseurs ne sont pas nécessairement nécessaires pour cela. Votre abstraction peut lui-même être un modèle de vue, qui présente ensuite des sous-classes spécifiques à la plate-forme. Par exemple, vous pourriez avoir un modèle Color Afficher le modèle et un WPFColor Modèle héritant de cela.
Dans le modèle de modèle de présentation d'origine décrit par Martin Fowler, la vue "demande" le modèle de vue comment s'afficher. Cela semble favoriser la mise en place de la couleur et des propriétés de la taille sur votre modèle de vue plutôt que des déclencheurs à votre vue. L'application de ce modèle au sein du WPF est cependant quelque peu différente. Dans WPF, vous définissez généralement également dans le modèle de modèle de présentation d'origine, le modèle de vue est une abstraction Voilà ma réponse et je suis en train de m'en tenir, mais il est également intéressant de considérer des arguments dans l'autre sens. Pour une, la mise en place de propriétés de couleur sur votre modèle de vue est toujours unitaire témoignable, ce qui semble être devenu les principaux critères de ce qui est correct dans le modèle de vue.
restant "agnostique" à la technologie de vue n'est pas un facteur énorme dans les deux sens. L'objectif de maintenir la compatibilité binaire des modèles de vision avec d'autres technologies de vue est réaliste que dans la famille XAML. Déplacer tous vos modèles de vie à leur propre projet qui manque de dépendance directe sur le WPF est une bonne idée. Mais vous devriez exclure tout ce qui utilise l'iCommand ou faire une exception pour une référence WindowsBase.dll. Pratiquement parlant, cependant, cela ne vous achètera pas beaucoup. Nous sommes à peu près collé à Micrsoft Technologies! Si vous décidez de porter dans un autre cadre d'interface graphique, je suppose que vous envisagez de la conversion de code source. J'attends de voir si Microsoft passe avant que je l'essaie;) Le portage pourrait inclure la modification de vos types de couleurs, si vous avez décidé de les mettre dans votre modèle de vue. Bien que ce ne soit pas une raison contre les propriétés de couleur sur votre modèle de vue, ce n'est pas nécessaire la raison de celle-ci non plus.
En voyant les votes récents sur ma réponse, je voulais mentionner que les bibliothèques de classe portables (PCL) dans .NET 4.5 permettent le partage binaire de modèles de visualisation sur les applications de Microsoft XAML Technologies (WPF, Silverlight et Style METRO-Style). Dans une PCL, vous pouvez faire référence à ICommand comme s'il s'agissait de la même interface sur les technologies XAML. Je ne crois pas que les couleurs ou les brosses, cependant, sont compatibles binaires à travers les technologies.