MVVM de A à Z
•Als PPTX, PDF herunterladen•
3 gefällt mir•4,508 views
Pattern de référence pour les applications WPF, Silverlight et Windows Phone, MVVM est de plus en plus utilisé. Cette session d’introduction vous permettra de découvrir les différents éléments qui le compose, leur mise en place et surtout de bien comprendre quand, comment et pourquoi utiliser ce pattern ne peut que vous être profitable !
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie MVVM de A à Z
Ähnlich wie MVVM de A à Z (20)
Mehr von Microsoft
Mehr von Microsoft (20)
MVVM de A à Z
- 1. palais des congrès Paris 7, 8 et 9 février 2012
- 2. MVVM de A à Z 08/02/2012 Arnaux AUROUX Thomas LEBRUN Consultant Consultant Infinite Square Infinite Square MVP Client App Dev
- 3. INFINITE SQUARE en quelques mots… Société de conseil, expertise, réalisation, et formation, exclusivement sur les technologies Microsoft de développement d’applications et de la plateforme applicative 25+ collaborateurs spécialisés sur les techno MS, dont 10 MVP… GOLD Certified Partner sur 4 domaines de compétences Agréé CIR Centre de formation agréé
- 4. Agenda Les enjeux du développeur Les modèles MVC et MVP Le XAML Pourquoi utiliser le pattern MVVM ? Anatomie du pattern Les différentes philosophies Tests unitaires Pour aller plus loin…
- 5. Les enjeux du développeurs Couplage Business Class 1 Business UI Class 1 Class 2 Data Class 1 Data Class 2 UI Class 2 UI Class 3 Business Class 3 Data Class 3
- 6. Les enjeux du développeur Les conséquences Applications monolithiques Difficilement maintenable Difficile à faire évoluer Non réutilisable Difficilement testable Régressions
- 7. Les enjeux du développeur Comment régler les problèmes de couple ? Devenez célibataire! Séparation des responsabilités (principe SRP) Maintenabilité Evolutivité Testabilité
- 8. Les modèles MVC et MVP Les modèles existant MVC, MVP Model : la donnée View : l’écran Controller, Presenter : l’intéraction entre l’écran et la donnée Utilisation sur des projets .Net, Java, etc.
- 9. Les modèles MVC et MVP Les modèles existant Controller View View Presenter Model Model Model View Controller Model View Presenter
- 10. Le XAML XAML Windows 8
- 11. Le XAML Présentation Langage de description <Grid Margin="20"> d’interfaces graphiques <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition /> <RowDefinition Height="Auto" /> Format XML </Grid.RowDefinitions> <TextBlock Text="Liste de produits" Grid.Row="0"/> <ListBox Grid.Row="1> Facile à maintenir et à <ListBoxItem Content="Produit 1"/> <ListBoxItem Content="Produit 2"/> réutiliser <ListBoxItem Content="Produit 3"/> </ListBox> <Button Content="Ajouter produit" Interprétable par différents </Grid> Grid.Row="2" /> outils Visual studio Expression Blend Internet explorer …
- 12. Le XAML <Button Width="100“ Height="30" Déclaratif Click="OnClick" Background="LightBlue"> OK </Button> Page.xaml private void OnClick(object sender, RoutedEventArgs e) Impératif { MessageBox.Show("Clic !"); } Page.xaml. cs
- 13. Le XAML Paper JPG / TIFF PSD C++ XAML PPT C# VB.NET MOV / WMV
- 14. Le XAML DataBinding : Connexion entre l’UI et les données Cible du binding Source du binding TextBlock Objet de données « Produit » Propriété Binding Propriété « Text » « Nom » Définition de la source du Binding via la propriété DataContext Définit par la classe FrameworkElement Héritage du DataContext
- 15. Pourquoi utiliser le pattern MVVM ? Pour les mêmes raisons que MVC et MVP Model : Les données View : L’UI ViewModel : Le pivot entre les données et l’UI Pour tirer pleinement profit des nouveaux concepts apportés par le XAML MVVM ? Une version de MVC, MVP adaptée au XAML
- 16. Pourquoi utiliser le pattern MVVM ? Démo: Ce qu’il ne faut pas faire !
- 17. Anatomie du pattern VIEW VIEWMODEL MODEL Actions Objets métier Contrôles UI Etats Règles métier Mise en page Exposition des Accès aux données Evènements données Validation Animations Binding Transitions Logique fonctionnelle
- 18. Anatomie du pattern Model Données Objets métier (Client, Produit, etc.) Transverse par rapport aux domaines fonctionnels Services Fournissent les requêtes de données Règles métier pour la mise à jour, suppression, etc.
- 19. Anatomie du pattern Model VIEWMODE SERVICE DAL L GetProduitsByPeriod(begin, LinqToXML end) EntityFramewo GetProduitByName(name) rk … … <<Produit>>
- 20. Anatomie du pattern Model Répercussion des modifications sur l’UI interface INotifyPropertyChanged Evènement PropertyChanged Validation Exception interface IDataErrorInfo Peut être décliné en 2 versions Version globale Version cliente
- 21. Démo: Implémentation du Model
- 22. Anatomie du pattern ViewModel Fait le lien entre les données à traiter et l’interface utilisateur Exposition de propriétés pour afficher/récupérer des valeurs Utilisation de commandes pour interagir avec l’utilisateur Définit l’intelligence applicative entre la donnée et sa représentation Implémente également INotifyPropertyChanged Elément entièrement indépendant de l’UI Testabilité Réutilisabilité avec d’autres vues
- 23. Anatomie du pattern ViewModel Les commandes Gestion découplée de l’interaction utilisateur Interface ICommand Méthodes Execute & CanExecute Implémentée en standard par certains contrôles Button CheckBox …
- 25. Anatomie du pattern View Typiquement un écran de l’application En charge de la mise en page des données pour les présenter à l’utilisateur Couple .xaml / .xaml.cs Ne contient aucune logique/dépendance métier On peut par contre y mettre du code relatif à l’UI (n’hésitez pas !)
- 26. Anatomie du pattern View DataTemplate Représentation visuelle d’un objet (arbre XAML) Resource donc réutilisable Contextualisation de la donnée Produit Nom : Produit 1 Prix : 20 Disponibilité : 08/02/2012
- 27. Anatomie du pattern View Design Time Utilisation d’un ViewModel factice pour le design de la View Réaction de la vue aux données Meilleure efficacité dans la collaboration designer/developpeur Outils de design time fournit par Expression Blend
- 28. Démo: Implémentation de la View
- 29. Les différentes philosophies Approche « View First » La View est l’élément directeur, elle instancie le ViewModel Avantages Simplicité d’implémentation Design Inconvénients 1 seul ViewModel possible par vue
- 30. Les différentes philosophies Approche « ViewModel First » Le ViewModel est l’élément directeur, il instancie la View. Utilisation des DataTemplates implicites. Avantages Souplesse pour le développement métier Inconvénients Support du DataTemplate implicite « Blendabilité » réduite
- 32. Les différentes philosophies Approche « Model First » Le Model est l’élément directeur, approche Data centrique Exemple : Microsoft LightSwitch Avantages Réalisations rapides: les écrans sont générés depuis les données Utilisation des assistants (drag&drop depuis Visual Studio) Inconvénients Support du DataTemplate implicite Possibilité d’un temps de chargement plus long Vue complexe = potentielles lenteurs
- 34. Les différentes philosophies Quelle philosophie adopter ? Importance du design VS Complexité fonctionnelle ViewFirst ViewModelFirst Mais surtout… n’ayez pas peur de varier les plaisirs ! Les approches ViewFirst et ViewModelFirst peuvent coexister.
- 35. Les tests unitaires Assurer la qualité de l’application Valider unitairement une fonctionnalité Automatisation Testabilité de la couche ViewModel Etats Opérations Testabilité de la couche Model Règles métier
- 36. Démo: Ecriture de tests
- 37. Pour aller plus loin… Frameworks MVVM MVVM Light Toolkit ( Prism ) Cinch … Liste descriptive : http://www.japf.fr/silverlight/mvvm/
- 38. Pour aller plus loin… MVVM: De la découverte à la maîtrise http://www.digitbooks.fr/catalogue/mvvm-antoine- lebrun.html
- 39. Conclusion Maintenabilité et pérennité de l’application Simple à implémenter, MVVM est votre ami C’est un modèle de développement, une ligne directrice : Adaptez le à vos besoins !
- 40. Questions ?
- 41. Pour aller plus loin Prochaines sessions des Dev Camps Chaque semaine, les 10 Live Open Data - Développer des applications riches avec le février DevCamps 2012 16 Meeting protocole Open Data ALM, Azure, Windows Phone, HTML5, OpenData février Live Meeting Azure series - Développer des applications sociales sur la plateforme Windows Azure 2012 http://msdn.microsoft.com/fr-fr/devcamp 17 Live Comprendre le canvas avec Galactic et la librairie février Meeting three.js 2012 Téléchargement, ressources 21 février Live La production automatisée de code avec CodeFluent Meeting Entities et toolkits : RdV sur MSDN 2012 2 mars Live Comprendre et mettre en oeuvre le toolkit Azure pour http://msdn.microsoft.com/fr-fr/ 2012 Meeting Windows Phone 7, iOS et Android 6 mars Live Nuget et ALM 2012 Meeting Les offres à connaître 9 mars 2012 Live Meeting Kinect - Bien gérer la vie de son capteur 90 jours d’essai gratuit de Windows 13 mars 2012 Live Meeting Sharepoint series - Automatisation des tests Azure 14 mars Live TFS Health Check - vérifier la bonne santé de votre www.windowsazure.fr 2012 Meeting plateforme de développement 15 mars Live Azure series - Développer pour les téléphones, les 2012 Meeting tablettes et le cloud avec Visual Studio 2010 Jusqu’à 35% de réduction sur Visual 16 mars Live Applications METRO design - Désossage en règle d'un Studio Pro, avec l’abonnement MSDN 2012 Meeting template METRO javascript 20 mars Live Retour d'expérience LightSwitch, Optimisation de www.visualstudio.fr 2012 Meeting l'accès aux données, Intégration Silverlight 23 mars Live OAuth - la clé de l'utilisation des réseaux sociaux dans 2012 Meeting votre application
Hinweis der Redaktion
- Tom
- Tom
- Tom
- ArnaudProblème général – ensemble de complexités – décisions – séries d’actions – nous ne sommes omnicients – action soumise à une série de variable qui peuvent changer la donne – degré de souplesse – sinon un seul changement peut causer l’effrondement des actions prises – même problème pour le dev d’application – application pour résoudre un problème – action = développer un écran, règles métier, accès aux données – lien naturel entre les actions car même application – modification sur une brique peut avoir un impact qui se propage via ces liens => pas acceptable
- Arnaud
- ArnaudSéparation des responsabilités : une classe doit gérer une responsabilité unique, une responsabilité doit être vu comme un regroupement de fonctionnalités ayant un sens fonctionnel commun.
- Arnaud
- ArnaudModel: les objets à afficher dans la vueVue : Représenter graphiquement les différentes propriétés du modelMVC : Controller ->Gère les intéractions entre la view et le model, chaque action passe par le controllerMVP : Presenter -> Basé en grande partie sur le MVP, pproche plus découplée que le MVC, le presenter ne connait pas directement la view. Le presenter se situe entre la view et le model, ils sont entièrement indépendant l’un de l’autre, le presenter met à jour la view par rapport aux états du model
- Tom2D, 3D drawing, animations, styling, document flow
- Tom
- Tom
- Tom
- Tom
- Tom
- Tom
- Tom
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Arnaud
- Tom
- Tom
- Arnaud
- Tom
- Arnaud
- Tom
- Tom
- Arnaud
- Tom + Arnaud
- Tom
- Arnaud