Comme ca fait quelques temps que je n’ai pas écrit de billet et que j’ai envie de partager mon expérience sur le sujet, j’en profite

Je suis globalement d’accord avec lui, respecter tout MVVM n’est pas forcément toujours judicieux. Il faut l’adapter aux besoins de l’application.

En général, j’adapte mon utilisation de MVVM en fonction de l’application que je crée. Par contre, aujourd’hui, je ne concevrai pas de créer une application sans MVVM.

Je trouve que le découplage est beaucoup plus clair et j’ai remarqué pour ma part que j’écris plus rapidement mon application en utilisant un viewmodel qu’en utilisant le code behind. De même, un ressenti totalement subjectif et pifométrique me fait trouver que je fais moins de bugs.

Donc, une application sans mvvm ? non. Maintenant que j’y ai gouté, je ne peux plus m’en passer. Par contre, suivant l’application, je respecte plus ou moins le pattern.

Je trouve qu’un des valeurs ajoutées du pattern est qu’il force à utiliser le mécanisme de binding. Il est trop tentant (pour aller vite) de faire du monTextBlock.Text = “…”.

Pour moi ca n’apporte rien, à part des bugs

J’ai vu trop de gens ne rien comprendre au binding et c’est bien dommage. Donc oui au binding, forcé par mvvm.

Je suis d’accord qu’on peut se demander vraiment l’utilité d’un locator et en général, pour une petite application rapide, je ne m’en sers pas. Par contre, je rajoute dès que possible l’utilisation des commandes, notamment grâce à la classe RelayCommand qu’on trouve dans MVVM-Light.

Il est vrai que pour une application rapide, pour un test ou autre, j’ai tendance à ne pas embarquer de dépendances (donc pas de RelayCommand ou autres systèmes de messagerie) et donc j’utilise le code-behind pour récupérer mon viewmodel et lancer les commandes. Ca créé un couplage, mais est-ce bien grave ?

Par contre, dès que l’application est un tant soit peu sérieuse, on ne peut pas s’en passer.

Je partage également le point de vue d’Olivier qui dit qu’on peut vite se perdre avec un système de messagerie (je n’utilise pas celui de MVVM-Light). J’ai l’impression de m’en sortir mieux maintenant en me fixant quelques règles de nommages, d’utilisation. Il est vrai qu’il n’y a pas de guidelines pour et qu’au démarrage on peut vite s’embrouiller… mais avec un peu de pratique, je trouve qu’on peut l’utiliser avec profit.

Les boites de dialogues ? Oui, c’est vrai, c’est casse-pied Mais comme j’ai tendance à ne pas trop en faire et plutôt à afficher des confirmations sous une autre forme, ca ne m’embête pas trop trop. Quand j’en ai besoin, le système de messagerie me rend bien des services.

Les tests unitaires ? J’ai beau être un adepte convaincu du testing, j’avoue ne pas m’en servir pour tester les viewmodels. Je préfère blinder la couche d’accès aux données ou la couche de service.

Dans un des commentaires, on peut lire une remarque sur la création de contrôles personnalisés remplies de DependencyProperty juste pour faire du MVVM qui, pour le commentateur, est un problème. Il est vrai que créer des contrôles utilisateurs juste pour ca, c’est un peu dommage. Par contre, dans certains cas, je trouve que ca apporte un découplage complémentaire et offre une réutilisabiilté. Certains behavior sont tout à fait pertinent.

Bref, voici mon retour d’expérience.

En conclusion : Oui pour MVVM, il faut dans un premier temps faire dans l’extrémisme pour pouvoir comprendre et apprécier les avantages du patron de conception et ensuite y revenir et l’adapter vraiment au besoin.

Et vous ? Votre expérience ?

Dans ce premier tutoriel, vous découvrirez comment démarrer le développement d’applications avec Windows Phone 7.
Nous commencerons par installer les outils nécessaires au développement sur WP7 puis nous créerons un premier programme simpliste en utilisant Silverlight pour WP7.
Enfin, nous l’exécuterons sur l’émulateur et découvrirons son fonctionnement.

Bonne lecture : http://nico-pyright.developpez.com/tutoriel/vs2010/csharp/windows-phone-seven/introduction-developpement-windows-phone-seven-wp7-silverlight/

Cet article constitue une introduction au développement d’applications Silverlight en utilisant le design pattern M-V-VM grâce au MVVM Light Toolkit de Laurent Bugnion.

Bonne lecture

Ainsi, on peut imaginer 2 méthodes d’extensions qui font ca :

A utiliser ainsi :

Aller consulter l’article

Bonne lecture

Pour ce faire, on va créer nos deux objets en C# coté Silverlight en utilisant l’attribut ScriptableMember.

Il faudra ensuite enregistrer le type de retour coté javascript, grace à HtmlPage.RegisterCreateableType :

Ainsi, coté javascript, on pourra exploiter ce type dans la fonction :

Dans le javascript, on va créer l’objet qui va nous servir pour retourner les valeurs à Silverlight et le renseigner en conséquence.

Enfin, coté Silverlight, on appelle la fonction javascript grace à HtmlPage.Window.Invoke en lui passant l’objet de paramètres.

On récupère un objet de type scriptObject dont on pourra caster le contenu de ManagedObject en notre type de retour.

Pour ce faire, on va utiliser l’objet javascript clipboardData et invoquer la méthode setData :

NB : le retour de la méthode Invoke étant un type simple, on peut le caster directement en ce type (ici, bool)

Plus bas dans notre page, nous avons notre composant Silverlight et un div contenant du texte :

Grace à la méthode Invoke de l’objet HtmlPage.Window nous pourrons appeler la fonction javascript depuis Silverlight et changer ainsi la visibilité de notre div :

qui contient un controle <asp:Silverlight>et un <div> identifié par son id : « result »

On utilisera la classe System.Windows.Browser.HtmlPage, par exemple, lors du click sur un bouton Silverlight, on pourra faire :

Ainsi, on pourra modifier le contenu du div depuis notre application Silverlight