Questions d'architecture autour de EDM et WPF

Bonjour à tous,

je vous propose de discuter des différentes possibilités d'implémentation d'une application métier dont l'architecture repose sur les technos suivantes :

• EDM pour l'accès aux données, leur encapsulation sous forme objets métiers et leur persistance.
• WPF pour la conception de l'UI.

Je propose que chacun pose les problèmes qui l'intéresse et le débat portera sur les différentes solutions envisageables (et les possibilités de consensus mais là faut pas trop en demander :mouarf:).

PS : je rappelle qu'on parle uniquement d'appli métier basée sur EDM + WPF

Alors je commence avec une première problématique essentielle : le pattern utilisé pour la séparation des couches. :D

Perso, je suis séduit par le motif dit "MVVM", tel que présenté par Josh Smith ici. Cependant comme on peut le lire sur son blog, Josh n'est pas un adepte de l'EDM.

Quel modèle conviendrait donc pour le design des classes de la couche ViewModel en lien avec des objets EDM ?

Josh crée une classe de base implémentant INotifyPropertyChanged et destinée à servir de wrapper aux objets métiers. Dans le cas de classes issues de l'EDM, on pourrait peut-être appliquer un pattern de composition (au lieu de wrapper) et exposer par exemple directement une instance métier comme propriété en lecture seule. C'est une possibilité car elle évite de créer un wrapper et les classes métiers EDM implémentent déjà INotifyPropertyChanged. À discuter...

Quoiqu'il en soit d'une manière plus générale, je trouve que le pattern MVVM impose de fournir deux catégories de services dans les classes ViewModel :

1. UIProvider : exposer à la couche métier des accesseurs en lecture/écriture aux données métiers (via des propriétés CLR) et une notification de modification (via l'interface INotifyPropertyChanged).
2. DataAdapter : exposer des services de chargement et persistance des données métier.

Je vais ici me concentrer sur la partie "UIProvider" : une partie des services UIProvider est fournie avec le wrapper ou la composition exposant les propriétés de l'objet métier (soit directement soit via son instance).
Mais il demeure une autre partie : assurer à la couche UI la notification des changements pour lesquels l'événement INotifyPropertyChanged.PropertyChanged ne suffit pas.

Ce cas de figure se présente par exemple lorsqu'on travaille avec des vues de collections filtrées, triées ou regroupées. Par conséquent, pour obtenir une mise à jour de l’affichage de la vue sans provoquer une itération systématique sur tous les éléments de la collection sous-jacente, il est possible de déclencher l’événement CollectionChanged de la collection sous-jacente (en supposant qu'elle implémente INotifyCollectionChanged). Voici là une piste sur le "comment". Mais la difficulté provient plutôt du "quand" effectuer cette notification.

Perso, je trouverais dommage de devoir souscrire à l'événement Propertychanged de toutes les instances d'objets métiers en cours pour détecter tout changement susceptible d'impacter une vue affichant l'instance modifiée. Je pense qu'il serait plus pertinent de ne "surveiller" que les instances réellement susceptibles d'être modifiées. On pourrait les appeler instances "actives" ou "sélectionées" (peu importe). L'idée, c'est que dans l'UI on ne peut modifier manuellement qu'un nombre limité d'élément à la fois (strictement parlant, un seul car pour en mofifier plusieurs à partir d'une action utilisateur il faut du code et donc la procédure de mise à jour dispose alors en général de moyens supplémentaires pour faire connaître ses changements contrairement à la seule infrastructure WPF agissant à partir d'éléments définis en pur xaml). Donc mieux vaudrait tracer uniquement cet élément "actif", "sélectionné" ou "édité". Là plusieurs possibilités existent... Avec code-behind, uniquement en xaml, etc.

Qu'en pensez-vous ?

Fred is back ! :mouarf:

Perso, j'ai commencé à regarder MVVM et je le trouve très intéressant, surtout car il permet vraiment d'être faiblement couplé ce qui facilite grandement les tests unitaires.

Après, je n'ai pas trop regardé EDM donc je ne sais pas ce que cela vaut avec ce pattern mais je vais essayer de creuser ca....

Citation:

---

Perso, je suis séduit par le motif dit "MVVM", tel que présenté par Josh Smith ici.

---

Ah oui, j'ai lu cet article il y a 2 jours, vraiment pas mal du tout...

Par "EDM" tu veux parler d'Entity Framework je suppose ?

J'ai déjà fait un petit projet perso utilisant Entity Framework et WPF, et j'avais rencontré pas mal de soucis sur le binding, que j'avais contournés par des moyens plus ou moins élégants... (bon, ok, c'était carrément crade :aie:)

Mais à l'époque où j'ai développé ça je ne connaissais pas MVVM, et je pense que ça devrait changer la donne... Tout ce que j'ai lu à ce sujet me donne assez envie de reprendre mon projet en appliquant le pattern MVVM, faudrait juste que je trouve un peu de temps pour m'y remettre :roll:

Par contre j'ai pas bien compris ce qui te pose problème par rapport aux notifications de modifs...

Quels avantages de MVVM sur MVP ?

Citation:

---

Envoyé par anthyme

Quels avantages de MVVM sur MVP ?

---

Justement Josh Smith en parle dans son article
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Contrairement à MVP, MVVM a été conçu spécifiquement pour WPF, en tenant compte des possibilités de WPF (binding, commandes, ICollectionView...)

Pour moi, le principal avantage est que grâce au binding, le ViewModel n'a aucune référence vers la vue, et la vue n'a aucune référence statique vers le ViewModel... donc tu peux facilement les interchanger, tester le ViewModel indépendemment de la vue, etc...

Pour ma part, j'ai découvert le MVVM et notamment l'article de Josh grâce au blog de thomas. :)

Citation:

---

Envoyé par tomlev

Par "EDM" tu veux parler d'Entity Framework je suppose ?

---

Ouaip !

Citation:

---

Envoyé par tomlev

Par contre j'ai pas bien compris ce qui te pose problème par rapport aux notifications de modifs...

---

En effet je pense que je pinaille un peu sur cette question. J'ai poussé le perfectionnisme un peu loin, peut-être jusqu'à une voie sans issue (ce serait pas la première fois). :aie:
En général, j'ai une phobie pour les abonnements intempestifs aux événements et pour les boucles à répétition sur les collections... :lol:
En l'occurence, je vais expliciter un peu de manière à profiter aux mieux de vos avis mais aussi pour aborder éventuellement une autre problématique...

Nous savons que INotifyPropertyChanged permet à l'UI WPF de rester synchro avec les modifications des données. De même pour l'interface INotifyCollectionChanged qui permet aux vues de rester synchro lors des opérations classiques sur les collections (ajout, suppression, etc.).

Toutefois j'ai remarqué dans le cas des vues que INotifyPropertyChanged ne suffit pas à une vue pour mettre à jour son tri, son filtrage ou ses groupes. Ceci est problématique lorsque le tri, filtre ou regroupement est basé sur la propriété qui a été modifiée. Maintenant là où je chipotais un peu, c'est pour les solutions à ce problème. :ange:

Je vais vous faire part de mes tests et de la solution que j'envisage actuellement.

Après tests (sur des vues ListCollectionView et ItemCollection), j'ai remarqué que la méthode Refresh d'une vue ne permet pas de mettre à jour le tri, le filtrage ou les groupes.
Par contre il suffit de déclencher artificiellement l'événement CollectionChanged de la collection source pour obtenir que la vue dans WPF se mette à jour correctement. J'écarte la solution de redéfinir le filtre de la vue car cela oblige à créer du code-behind, cela ne concerne a priori que le filtre, et enfin cela oblige à passer en revue tous les items de la collections source un par un (l'une de mes phobies :P) avec les critères du filtre.

Donc ma solution : faire ce que faisait déjà Josh Smith, c'est à dire inscrire un gestionnaire pour l'événement PropertyChanged de chaque Item ajouté à la collection. Cela se passe dans l'objet ViewModel qui expose la collection. Lui le faisait pour surveiller les items sélectionnés dans l'UI (et faire un calcul dessus), moi j'en aurai besoin pour déclencher artificiellement l'événement CollectionChanged si je sais que cette collection est triée, filtrée ou regroupée dans l'UI.

Pour déclencher l'événement artificiellement, je déplace dans la collection l'item modifié (par exemple avec la méthode ObservableCollection.Move).

Voilà. Maintenant, l'optimisation que j'essayais d'obtenir était la suivante : ne pas inscrire de gestionnaire systématiquement lorsqu'un item est ajouté à la collection, mais ne le faire que lorsqu'un item est sélectionné dans l'UI (ou avant qu'il ne soit modifié par code). Car après tout, il est vrai que je n'ai besoin de surveiller les changements que de l'item actuellement sélectionné, vu que pour le modifier il faut d'abord le selectionner... J'espère que je suis assez clair. :aie:
Bref, le problème est que cela devient un peu lourd et complexe de mettre en place la détection et la notification de la sélection d'un item dans l'UI (pour ensuite s'abonner si nécessaire à l'événement Propertychanged de l'item sélectionné). Donc on augmente le risque d'erreur ou d'une maintenance plus délicate. Mais cela reste faisable.

A la limite (et c'est là que surgit l'autre problématique que j'annonçais au début) l'idée de détecter la sélection peut-être justifiée si on ne s'en sert pas uniqument pour le problème de rafraîchissement de vue que je viens d'évoquer.
L'article de josh fournit un exemple où détecter la sélection d'un item dans l'UI est pertinent (pour calculer dynamiquement le total des ventes que représentent les items sélectionnés).
Là il peut devenir intéressant de mettre en place un sytème de détection plus poussé, notamment si on veut pouvoir faire la différence entre plusieurs sélection d'un même item au même moment par différents éléments UI. Vous remarquerez au passage que dans la démo de Josh, l'objet qui surveille la sélection de ces items est en singleton. Ce n'est pas un hasard : c'est parce que son concept de sélection tel qu'il l'a implémenté n'est pertinent que pour une seule vue de sa collection. Mais on pourrait avoir besoin de différencier les sélections d'un même item (même instance) dans plusieurs éléments UI. Cela peut se produire surtout quand on essaie de créer des ViewModel le plus déconnectés possible de leur vues (ce qui est le principe des ViewModel...).
Bon je m'arrête là sur ce sujet car personne ne va lire... :lol:

Citation:

---

Envoyé par tomlev

Pour moi, le principal avantage est que grâce au binding, le ViewModel n'a aucune référence vers la vue, et la vue n'a aucune référence statique vers le ViewModel... donc tu peux facilement les interchanger

---

Interchanger, oui, clairement. Mais dans la pratique, même s'il n'y a plus de référence de la vue vers la couche ViewModel (contrairement à la couche Controler du pattern MVC) je crois que le couplage disons "conceptuel" reste assez fort. Il n'y a qu'à voir les exemples discutés au dessus à propos du concept de (multi)sélection d'un item dans l'UI ou de la nécessité (éventuelle) de savoir si une vue est filtrée, triée ou regroupée dans l'UI. Cependant le découplage disons "technique" est réel, et cela permet théoriquement d'interchanger très facilement. A coup sûr en tout cas, ça permet de gagner en lisibilité et donc en maintenance / évolutivité. :)

J'attends toujours avec un intérêt vos remarques sur des points évoqués précédement, mais j'aimerais lancer une autre question se rapportant au débat :

Dans quelle mesure serait-il pertient de fusionner les couches "Model" et "ViewModel" (pour reprendre les termes du pattern MVVM) ?

Arguments pour :

1. Possibilité d'implémenter les services ViewModel dans les classes d'entités métier grâce aux classes partielles <Mode PorkyOrNotPorkyThatIsTheQuestion> ou même à l'héritage (la classe implémentant les services type Provider et Adapter pour UI pouvant carrément hériter du type de l'entité métier )/>.
   
2. Les classes métier sont générées par un outil en tant que classe partielle. Autrement dit on peut facilement "nettoyer" le modèle ou en générer un autre, ce qui diminue la nécessité de maintenir séparée la couche du modèle, d'autant plus qu'en définitive, le modèle est bien défini séparément, à savoir dans le fichier CSDL (Conceptual Schema Definition Language)
   
3. Les classes métier générées implémentent déjà INotifyPropertyChanged et globalement, les services fournit par EDM (type Provider, Adapter, Suivi de modification...) empiètent sur les responsabilités et la raison d'être du ViewModel.
   
4. L'exigence de maintenir une couche ViewModel séparée afin de pouvoir la conserver en cas de changement de la couche Model est parfois illusoire. Car il y a un couplage fort à la fois conceptuel et technique (référence statique du ViewModel vers Model).

Arguments contre :

1. On est plus dans un motif MVVM à proprement parler :aie:
   
2. La division et séparation nette des couches permet de gérer des projets (très) lourds et complexes (or qui peut le plus, peut le moins)

Citation:

---

Envoyé par FRED.G

Pour ma part, j'ai découvert le MVVM et notamment l'article de Josh grâce au blog de thomas. :)

---

Cool, y a quand même des gens qui le lisent alors :aie:

Citation:

---

Envoyé par FRED.G

Après tests (sur des vues ListCollectionView et ItemCollection), j'ai remarqué que la méthode Refresh d'une vue ne permet pas de mettre à jour le tri, le filtrage ou les groupes.

---

Si tu modifies les GroupDescriptions, SortDescriptions, ou le Filter d'une ICollectionView, la vue se met à jour toute seule, non ?

Citation:

---

Envoyé par FRED.G

Dans quelle mesure serait-il pertient de fusionner les couches "Model" et "ViewModel" (pour reprendre les termes du pattern MVVM) ?

---

Comme tu le dis plus loin, dans ce cas on est plus sur du MVVM (en fait, on retombe sur du Presentation Model, si j'ai bien compris ce que c'est...)
Je pense que c'est dommage, parce que le ViewModel permet d'adapter l'interface du modèle pour qu'elle soit facilement utilisable par la vue, sans toucher au modèle. Si tu utilises un modèle sur lequel tu n'as pas le contrôle, c'est presque indispensable...

je me documenter et tester ca sur mon prochain projet

(en silverlight je suppose que c'est pareil ?)

Citation:

---

Envoyé par tomlev

Cool, y a quand même des gens qui le lisent alors :aie:

---

Je parlais du blog CS de Thomas Lebrun. :oops:

Citation:

---

Envoyé par tomlev

Si tu modifies les GroupDescriptions, SortDescriptions, ou le Filter d'une ICollectionView, la vue se met à jour toute seule, non ?

---

Oui. Par contre tu ne peux pas faire cela sans code-behind, et dans le cas du filtre (pour le tri et le regroupement je ne connais pas les algos) tu es sûr de boucler sur tous les items de la collections source.

Citation:

---

Envoyé par tomlev

Comme tu le dis plus loin, dans ce cas on est plus sur du MVVM (en fait, on retombe sur du Presentation Model, si j'ai bien compris ce que c'est...)
Je pense que c'est dommage, parce que le ViewModel permet d'adapter l'interface du modèle pour qu'elle soit facilement utilisable par la vue, sans toucher au modèle. Si tu utilises un modèle sur lequel tu n'as pas le contrôle, c'est presque indispensable...

---

Pour ma part de ce que j'ai compris, on présente en général le Presentation Model comme une évolution ou disons plutôt une implémentation du pattern MVC permettant (au choix) que le PresentationModel ignore tout de la vue ou bien que la vue ignore tout du PresentationModel (afin toujours de faciliter la lisibilité, le dév et la maintenance en séparant au max les responsabilités). Paul Williams en discute ici. Il distingue ainsi deux implémentations du MVC : Presentation Model et View Helper. Comme l'explique Josh dans son article, MVVM est une 3ème implémentation du pattern MVC avec la même finalité que le Presentation Model (tel que décrit par Paul Williams) mais en étant profilé à 100% pour du WPF.

Bref en fusionnant la couche d'abstraction de la vue et les classes des données métiers, on sort carrément du pattern MVC au sens strict de 3 couches séparées, mais on conserve effectivement l'idée qui a émergé avec le pattern Presentation Model, à savoir la séparation d'un modèle abstrait de la vue et l'idée qui a donné sa raison d'être au pattern MVVM, à savoir être 100% WPF friendly...

En fusionnant l'implémentation du modèle abstrait de la vue et l'implémentation du modèle dit "conceptuel" de l'EDM dans un même projet par extension des classes partielles générées, on prend un raccourci un peu des deux côtés, ce qui simplifie le développement pour des relativement applis modestes et complètement controllées, mais qui n'est pas envisageable comme tu l'as dit pour un dev plus complexe où l'on ne maîtrise pas toutes les couches... Dans quelle mesure on contrôle la couche d'accès aux données et le modèle des entités métier ? Qui génère les entités EDM, utilisera-t-on toujours cette techno ?

Si on a un contrôle à 100%, pour tancher la question, je crois qu'il faut ensuite peser le pour et le contre entre devoir créer des Wrappers (donc en reproduisant peu ou prou l'interface publique du modèle métier, ce qui peut être fastidieux mais il existe des générateurs de code...) dans une couche ViewModel (pattern MVVM) ou bien étendre directement les classes partielles.

Une chose est sûre (c'est mon argument "pour" n°4) c'est que si on change le modèle (métier) l'implémentation de la couche ViewModel sera obselète. Donc en réalité on ne change pas la première sans la seconde...

Je reste quand même très indécis sur cette question et sollicite tous les avis. :)

Citation:

---

Envoyé par FRED.G

Je parlais du blog CS de Thomas Lebrun. :oops:

---

Ah, je me disais aussi :aie:

Citation:

---

Envoyé par tomlev

Ah, je me disais aussi :aie:

---

Ce débat n'aura pas été vain : sur un quiproquo, on aura au moins découvert ton blog ! :mouarf::mouarf:

Citation:

---

Envoyé par FRED.G

Après tests (sur des vues ListCollectionView et ItemCollection), j'ai remarqué que la méthode Refresh d'une vue ne permet pas de mettre à jour le tri, le filtrage ou les groupes.

---

Petite rectification et compléments après vérifications :
La méthode ItemCollection.Refresh ne rafraîchit rien.
Par contre, si je récupère la vue avec CollectionViewSource.GetDefaultView la méthode Refresh fonctionne (pour le filtre, tri et regroupement).
J'ai remarqué aussi que lorsque la sélection change dans la ListBox, l'événement CollectionViewSource.Filter est déclenché pour le nouvel élément sélectionné.

A part ça pour le fond du débat, n'hésitez pas à partager vos expériences / point de vue. En attendant j'essai de trouver des ressources en anglais sur cette question : quel pattern pour Entity Framework (EDM) + WPF.

Citation:

---

Envoyé par FRED.G

Oui. Par contre tu ne peux pas faire cela sans code-behind

---

Il est possible d'accéder aux SordtDescription, etc... directement depuis le XAML...

Je vais pas pouvoir apporter grand chose a la discussion (encore en 2.0, et pas pret de faire du WPF, donc...), mais vu ce matin, une beta d'un framework WPF/Silverlight, qui peut peut-etre apporter 2/3 reponses, cote archi...

http://devlicio.us/blogs/rob_eisenbe...a-is-live.aspx

Par contre, ca va probablement etre base sur du NHibernate ;)

Faut voir ce que donne ce FX mais cela peut-être intéressant, en effet.

Citation:

---

Envoyé par Thomas Lebrun

Il est possible d'accéder aux SordtDescription, etc... directement depuis le XAML...

---

Oui en utilisant une CollectionViewSource. Et dans ce cas il suffit d'utiliser Refresh pour avoir la vue à jour. Mais pour détecter quand déclencher un Refresh et pour le faire, il faut du code behind quelque part même si c'est pas méchant, par exemple pour modifier un contrôle ou fournir des services attaché...

Citation:

---

Envoyé par Thomas Lebrun

Faut voir ce que donne ce FX mais cela peut-être intéressant, en effet.

---

+1