suppose que j'ai une classe appelée 1 - Créez à nouveau toutes les propriétés du client sur le modèle de vue. Injectez l'instance client dans le modèle d'affichage et chaque propriétés réduira la valeur de cet objet client. L'avantage de cette méthode est que je peux créer une classe de base commune pour tous les modèles de vue et avoir une fonctionnalité courante sur place. L'inconvénient sera le temps requis pour créer à nouveau toutes les propriétés sur le modèle d'affichage et effectuer la maintenance.
2 - Dérive le modèle de vue du client. J'ai donc toutes les propéritines du client dans la vue. Mais cela ne me permettra pas d'utiliser une classe de base commune et de mettre la logique modèle de vue commune là-bas.
Je me demande donc quelle sera la meilleure méthode pour créer un modèle de vue? Y a-t-il des méthodes alternatives qui sont meilleures que ce que je pensais? client . Maintenant, j'ai besoin de rendre le client à la vue. Donc, j'ai créé CustomerViewModel à utiliser dans la liaison. Je cherche la meilleure façon de créer la catégorie CustomerViewelModel . Voici mes pensées sur la création.
3 Réponses :
Vous devriez envisager de lire Article de Josh Smith sur MVVM.
Il a également un cadre appelé MVVM Foundation qui a une classe de base de la vue. En général, je pense que la façon dont il implémente ViewModel est le meilleur général.
J'ai déjà vu ça. Il fait la méthode que j'ai décrite au point 1.
Oui ... je pense que c'est la meilleure méthode. J'ai travaillé sur un projet avec plus de 100 images de vue et c'était la meilleure méthode et le plus facile à entretenir dans l'ensemble. J'espère que cela pourra aider
Si votre classe client d'origine ne prend pas en charge la liaison des données, vous serez obligé de créer une classe de viewModel et de répliquer les propriétés de la classe client.
Si toutefois, votre classe client met déjà en œuvre la prise en charge de la liaison de données (il a des propriétés de dépendance ou des implements inotifypropertychanged), il n'y a pas de raison fondamentale pour laquelle vous ne pouvez pas lier directement contre les propriétés de la classe client.
Vous pouvez bien sûr disposer d'autres considérations - vous voudrez peut-être avoir votre viewModel exécuter certaines opérations en réponse à des modifications de propriété ou que vous ne souhaitez pas ne pas vouloir que des objets clients soient modifiés directement. Dans ce cas, vous voudrez toujours envelopper la classe client.
En outre, vous souhaiterez peut-être prendre en charge la validation des données via l'interface IDATAERRORINFO auquel cas si votre classe client n'implique pas cette interface, vous devrez probablement probablement l'envelopper.
L'option 1 est beaucoup mieux. La raison est que vous voulez pouvoir varier de manière indépendante ces deux couches. Avoir un couplage serré entre votre modèle de domaine et votre modèle de vue introduirez une rigidité dans votre processus de développement que vous souhaitez éviter.
La façon dont je traite de devoir écrire tant de code est que je ne le fais pas. J'utilise T4 modèles , des conventions raisonnables (propriétés, par défaut, montrent Dans le modèle de vue; les classes de modèle de domaine implémentent inotifypropertychanged et sont délégués à la hausse) et un fichier de configuration pour gérer la projection / l'aplatissement et générer les modèles de vue. Je les générais également comme des classes partielles pour pouvoir faire face à l'ajout d'un autre code si nécessaire.
Depuis combien de temps faut-il pour que vous puissiez répéter les propriétés du modèle dans la viewModel? Être capable de placer dans un convertisseur ou une gâchette à des fins d'affichage, cela vaut la peine d'être des minutes supplémentaires pour moi. Si vous avez une vue complexe avec de nombreux contrôles, ajoutez le modèle en tant que propriété dans la vue de la vue et de lier à Model.Property dans la vue.
Je tiendrais à l'écart de # 2. Je ne pense pas que vous allez toujours trouver une cartographie claire entre une classe de modèle spécifique et une vue de vue. Pour la maintenabilité, j'irais avec une autre classe qui pourrait logiquement s'asseoir devant le modèle personnalisé, mais pourrait également exposer d'autres types de modèles à l'avenir à la vue.