Hello,
hier j'ai commencé une application en utilisant le type de projet Pivot.
Dans la structure du projet, on peut voir un dossier nommé ViewModels.....
donc MVVM si j'ai bien compris !
Quelle est l'explication de cette base de départ ?
merci
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[WP7] Projet de type Pivot
Hello,
hier j'ai commencé une application en utilisant le type de projet Pivot.
Dans la structure du projet, on peut voir un dossier nommé ViewModels.....
donc MVVM si j'ai bien compris !
Quelle est l'explication de cette base de départ ?
merci
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
L'explication c'est que MVVM est le bon pattern à utiliser pour du développement Silverlight/WP7.
Ca permet également aux gens qui ne connaissent pas trop de voir une implémentation possible et d'investiguer les autres possibilités.
Après tu peux tout supprimer si ça t'intéresse pas.
Introduction à Silverlight 4 (new) ; Localisation d'une application Silverlight (new) ;
La connaissance s’acquiert par l’expérience, tout le reste n’est que de l’information. Albert Einstein[/SIZE]
Ok,
c'est pas un problème d'intérêt mais un problème de compréhension du pattern MVVM....
J'ai pas encore trouvé un tuto qui me parle.....
j'ai plus ou moins compris le Binding dans le MVVM mais le Locator et les commandes je n'arrive pas à comprendre.
De plus, ce qui n'est pas simple à comprendre aussi c'est le fait que les fichiers soient dispersés dans la solution et de ce fait il faut mettre des déclarations à droite ou à gauche....
et un coup c'est dans le XAML, un coup dans le App.xaml.cs , un coup dans le Locator ou le ViewModel etc....
et comme j'arrive après la bataille, je ne parviens pas à trouver un tuto qui explique tout ça clairement et simplement
Voilà pourquoi, pour le moment je fuis devant MVVM
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Ca s'appelle organiser son codeEnvoyé par DotNET74
Ce qui est du domaine visuel est dans le view (donc le user control ou le code behind de celui ci), ce qui est du modele de donnée (accès services, etc) c'est dans le model et la communication entre les deux se fait via viewmodel. Ainsi tu n'as pas d'accès aux données depuis le codebehind.
C'est fini le code spaghetti du winform
(J'ai cru comprendre que t'étais plus à l'aise sur winform: essaie de t'entrainer en appliquant le pattern MVC sur Winform)
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
J'ai du mal à comprendre pourquoi vous dite presque tous que WinForm c'est du code Spaghetti !!!
Mes applications étaient bien structurées.....
une WinForm avec son code, un Button dans cette Winform avec son code à lui, un DataSet etc....
je vois pas en quoi c'est Spaghetti ça!
en revanche, mettre une déclaration dans un XAML sinon il ne connaît pas le ViewModel qui lui même doit comporter une référence au Locator etc....
pour moi c'est plus du Spaghetti
parce que si tu sais pas qu'il faut déclarer dans un coin du XAML ton Locator ou autre rien ne se passe !
De plus, pourquoi toutes les pages d'une appli MVVM sont des UserControl alors que Microsoft à créer des Pages !!!!
bref
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Pour les pages/usercontrol c'est une simple question de logique: une page est une page et elle peut contenir plusieurs controles suivant les fantaisies du designer. Y'a pas à lui imposer un controle par page.J'ai du mal à comprendre pourquoi vous dite presque tous que WinForm c'est du code Spaghetti !!!
Mes applications étaient bien structurées.....
une WinForm avec son code, un Button dans cette Winform avec son code à lui, un DataSet etc....
je vois pas en quoi c'est Spaghetti ça!
en revanche, mettre une déclaration dans un XAML sinon il ne connaît pas le ViewModel qui lui même doit comporter une référence au Locator etc....
pour moi c'est plus du Spaghetti
parce que si tu sais pas qu'il faut déclarer dans un coin du XAML ton Locator ou autre rien ne se passe !
De plus, pourquoi toutes les pages d'une appli MVVM sont des UserControl alors que Microsoft à créer des Pages !!!!
bref
Concernant le code spaghetti:
Expliques moi dans ton code comment tu sépares en couches (et ca c'est pas spécifique au mvvm...)?
Comment tu découples tes couches?
Comment tu testes tes couches?
Comment tu partages tes couches entre différentes couches de présentation?
Comment tu exposes ta couche metier à l'exterieur via des services?
Je veux changer ma couche de présentation (Winform vers WPF) sans toucher ma logique métier, comment je fais?
Je veux changer ma couche d'accès au données (migration de SGBDR) sans toucher ma présentation, comment je fais?
On parle ici de vrai développement d'applications professionelles avec industrialisation de code.
Retrouvez moi sur :
Je veux bien croire que cela apporte un plus mais je ne suis pas persuadé que ce plus soit aussi grand que vous le dites.
car lorsque tu vas changer quelque chose dans ton application, il va falloir mettre à jour ton Locator par exemple puisqu'il n'aura peut être pas tout les ViewModels !
mais c'est un exemple !
De toute façon cela ne change pas mon problème par rapport à MVVM
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Le locator n'est qu'un exemple, tu peux t'en passer et faire de l'injection de dépendance via unity.Je veux bien croire que cela apporte un plus mais je ne suis pas persuadé que ce plus soit aussi grand que vous le dites.
car lorsque tu vas changer quelque chose dans ton application, il va falloir mettre à jour ton Locator par exemple puisqu'il n'aura peut être pas tout les ViewModels !
mais c'est un exemple !
De toute façon cela ne change pas mon problème par rapport à MVVM
Retrouvez moi sur :
Tu m'envois ravi !
vu que ça ne me dis rien non plus!!
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Retrouvez moi sur :
Merci,
le premier article est très parlant pour moi bien que je n'arrive pas à voir les similitudes avec le pattern MVVM.
En revanche le deuxième est très indigeste pour moi........
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager