Quels sont les principaux inconvénients de l'utilisation du modèle de présentation dans le code?

Question

Je suis en train de me préparer à être mis au défi avec la question:

"Pourquoi ne pouvons-nous pas implémenter le modèle de présentation dans le code derrière?"

En fait, j'ai travaillé sur un projet où nous avons utilisé un modèle de présentation qui a été implémenté dans le code. Cela a fonctionné assez bien, nous avons même pu faire des tests unitaires dessus. Oui vous avez une dépendance sur WPF dans vos tests unitaires ... mais ça marche! Quels sont les principaux inconvénients de l'utilisation du code derrière?

Je préfère l'idée d'un ViewModel indépendant (MVVM) mais pour l'instant je ne me sens pas capable de le justifier auprès des clients.

Answer 1

Vous avez répondu à la première partie de votre question, vous avez dû amorcer une application wpf pendant les tests unitaires. L'autre est la portabilité, voulez-vous pouvoir attacher différentes implémentations de vue au même modèle de présentation. (Faible, je sais mais c'est tout ce que vous avez)

Également la séparation des compétences, seuls les développeurs qui connaissent xaml seraient impliqués dans la définition de la vue. Vous permettant d'utiliser exisitng dans le talent de la maison qui ne sait pas wpf.

Answer 2

La réponse directe est la principle of separation of concerns. Bien sûr, quelqu'un pourrait faire valoir qu'en plaçant le modèle de présentation dans le code-behind, il est distinct de la vue (XAML), mais je ne suis pas d'accord avec cela. Le code-behind peut "voir" tous les détails internes de la vue parce que est la vue. Le xaml et le code-behind sont compilés ensemble dans une classe pour devenir la vue. Ils ne sont pas séparés du tout.

Il y a beaucoup d'exemples où vous devez aller dans le code-behind pour faire des choses liées à la vue, comme accrocher des interactions entre les contrôles que vous ne pouvez pas spécifier dans Xaml. Une fois que vous faites cela, vous avez maintenant votre logique de vue mélangée avec votre logique de présentation.

Le concept d'un ViewModel est assez puissant. ViewModels peut "se parler" sans que les vues "se parlent", ou même sans que ViewModels "sache" quoi que ce soit à propos des vues.

Answer 3

Cochez cette case pour avoir une idée. Les deux vidéos montrent le développement de l'application en commençant par tout ce qui est dans le code, puis ils refactorisent le modèle MVVM.

• Mike Taulty's series of videos (en fait il y a 10 vidéos au total, vérifier au moins une première et seconde)
• Jason Dolinger on Model-View-ViewModel

Aussi, voir cette question SO pour plus de liens: MVVM: Tutorial from start to finish?

Answer 4

il est devenu un inconvénient lorsque vous utilisez ViewModel-First approche. où, dans votre application principale, vous instanciez votre graphe d'objet ViewModel, affectez-le à la vue racine datacontext, puis laissez la vue afficher son enfant lié en fonction de la notification ViewModel.

Pourquoi est-ce un inconvénient? le fait que vous pouvez utiliser votre code, mais vous finirez avec un bounch de tricks et parfois forgot your application security. Mais en fait, cette approche est idéale, où votre modèle de vue totalement ignorant, même vous pouvez inverser votre processus de développement par le programme d'abord - peau dernier. (blague)

d'autre part si vous utilisez View-First approche, alors il n'y aura pas d'inconvénient, parce que viewmodel s'asseoir dessus. parce que le contrôle encore dans la vue si vous avez besoin de quelque chose de difficile comme l'utilisation de la boîte de mot de passe, alors faites-le naturellement comme ce que Microsoft nous a attribué ..

Espérons que cela aide.