2011-06-10 3 views
3

Dans une application WP dont l'approche est meilleure.Dans une application Windows Phone quelle approche est la meilleure?

  1. Sur la page XAML, appeler une méthode d'une autre classe (passer le délégué d'un .xaml.cs callback méthode) qui fait une demande au serveur, reçoit des données et lorsque les demandes complètes appelle le XAML. Méthode de page cs. et dans la méthode de rappel, nous obtenons des données et lions les données avec un contrôle (ListBox). Liez la zone de liste à un objet ObservableCollection de la classe MainViewModel.

  2. et changez l'objet délimité du MainViewModel. Tous les appels aux demandes au serveur sont faits dans la classe MainViewModel.

Répondre

4

Je vote pour l'option 2. Event les modèles de projet (par ex. Modèle d'application Databound pour Windows Phone 7) vous donne la MainViewModel et se fixe un Listbox à un ObservableCollection dans cette classe.

L'approche MVVC vous donne beaucoup plus de flexibilité, votre interface utilisateur est totalement séparée de la logique. Tout ce que votre interface utilisateur a besoin de savoir, c'est qu'elle est liée à un ObservableCollection et elle n'a pas besoin de savoir comment cette collection est remplie.

+0

Convenu, en gardant le plus de code hors des .xaml.cs vous permet d'écrire des tests automatisés pour ce individuellement (en supposant que vous contrôlez l'accès à ses dépendances, comme les requêtes web) –

+0

Merci, mais la première approche votre interface utilisateur reste également totalement séparée de la logique, et lorsque les contrôles d'exécution reviennent à la méthode de rappel dans xaml.cs je peux faire d'autres changements dans l'interface utilisateur comme afficher/masquer certains contrôles. et avec la deuxième approche si l'application est grande votre classe MainViewModel peut être de milliers de lignes, et difficile à gérer. – Ishti

+1

Vous n'êtes pas censé garder toutes les applications logique dans un MainViewModel, vous avez beaucoup de ViewModels qui ont la logique pour différentes parties de votre application. – texmex5

0

Je pense que vous devriez utiliser la seconde approche qui vous permet de créer des applications faiblement couplées. Les grands avantages de ces applications sont:

  • séparation des préoccupations: différents sous-systèmes/couches sont unité indépendante
  • test est simple
  • refactoring est augmentation plus facile
  • capacité à code réutilisation
  • ...

En ce qui concerne WP7, vous pouvez lire mon article qui montre comment le code en utilisant cette approche: a framework for building of WP7 application

Questions connexes