DependencyProperty et multithreading ?

bonjour

une dependencyproperty ne peut pas etre assignée par un autre thread

j'ai une dependencyproperty qui est un observable collection d'un classe héritant de dependencyobject

sur un autre thread je créé un autre observablecollection que je set sur ma dependencyproperty via un dispatcher.invoke dans le but de pouvoir au moins gérer mes données sur un autre thread
déjà ca plante (il me dit que le observable collection of maclasse n'est pas une valeur pour un observable collection of maclasee (aller comprendre ce que ca veut dire ...))

mais apparement les objets créé sur l'autre thread ne peuvent alors plus utilisés par le thread principal

en bref, les dependencyproperty c'est bien gentil, mais le multithreading est essentiel de nos jours, les 2 sont ils absolument incompatibles ??
microsoft ferait des modifs dans tous les sens sans pouvoir toutes les utiliser en meme temps (les parrallel.foreach arrivant sur le framework 4 en plus ...) ??

j'avais donne un link sur un sujet analogue
creer des uielement dans un trhead pour les passer au thread principal
tu devrais le regarder

je pense avoir retrouvé ton lien

la solution serait de transformer les uielement en xaml puis de les recréer sur le thread principal à partir du xaml
faudrait voir ce que ca donne niveau perf ...


mais est-ce que tout peut se transformer en xaml ? un dependencyobject aussi ??

c'est bien ce que je pensais, on ne peut pas tranformer n'importe quoi en xaml

mais question reste donc ...

Citation:

---

Envoyé par sperot51

mais apparement les objets créé sur l'autre thread ne peuvent alors plus utilisés par le thread principal

---

Seules les classes statiques et les objets qui sont dans un état gelé (Frozen) peuvent être échangés entre les threads.

Sinon, je ne comprend pas ta question/ton pb...

pour résumer, je rempli un observablecollection avec une classe héritant de dependencyobject

la collection est remplie et les objets instanciés sur un thread séparé

j'ai un binding sur une propriété de ma window

je veux placer la nouvelle collection dans cette propriété

et là ca plante
aux vues des différents messages d'erreurs, un dependencyobject ne peux pas passer d'un thread à l'autre, et un observablecollection non plus


et frozen n'existe que pour les classes graphiques ...

Je me permets de dévier un peu de la question de départ...
Quelle est le rôle de ta classe qui hérite de DependencyObject ? (métier/UI/autre ?) Est-ce qu'elle ne pourrait pas plutôt implémenter INotifyPropertyChanged ?

Si c'est pour un ViewModel (pattern MVVM), il est généralement admis qu'il vaut mieux implémenter INotifyPropertyChanged qu'hériter de DependencyObject (à ce sujet, voir cet excellent article, et cette discussion sur StackOverflow). Personnellement je préfère de loin l'approche POCO (INotifyPropertyChanged), parce qu'elle est beaucoup moins contraignante et donc beaucoup plus flexible (même si elle demande parfois d'écrire un peu plus de code).

je tente avec inotifypropertychanged pour voir ce que ca donne
mon bouquin préconisait les DP plutot que les propertychanged ...
et les DP ont l'air mieux niveau perf si j'ai bien lu



sinon je pourrais aussi dériver ma question de départ, wpf permet une parfaite synchronisation de l'interfaces avec des collections de données, avec très peu de code
mais comment faire pour synchroniser une base de données avec des collections ?

je suis parti sur un thread genre timer qui toutes les x secondes va lire dans la base pour faire que la collection reflète les éventuelles modifications qu'il y a eut (par un autre user par exemple)

qu'est-ce qui est le mieux niveau performance et volume de code ?
pour l'instant je recréé une collection à chaque tour, je compare cette collection avec la collection utilisée comme viewmodel et je fais les eventuelles modifs, ajout, suppression, ou modification d'une propriété, les clés ne changeant pas
pour l'instant je teste sur une classe avec deux propriétés donc ca se passe bien, mais y a t il une méthode plus adaptée à des grandes classes et des grands volumes de données ?

Citation:

---

Envoyé par sperot51

je tente avec inotifypropertychanged pour voir ce que ca donne
mon bouquin préconisait les DP plutot que les propertychanged ...
et les DP ont l'air mieux niveau perf si j'ai bien lu

---

Les DP sont parfaites pour certains usages, par exemple pour les propriétés de contrôles personnalisés, et d'une manière générale pour ce qui touche à l'interface graphique. Mais pour le reste... tu viens de voir par toi-même un des inconvénients majeurs :aie:
Pour ce qui est des perfs, l'auteur dit que les DP sont théoriquement plus performantes, mais que la différence est probablement négligeable. D'ailleurs ce serait intéressant de faire des tests là-dessus...

Citation:

---

Envoyé par sperot51

sinon je pourrais aussi dériver ma question de départ, wpf permet une parfaite synchronisation de l'interfaces avec des collections de données, avec très peu de code
mais comment faire pour synchroniser une base de données avec des collections ?

je suis parti sur un thread genre timer qui toutes les x secondes va lire dans la base pour faire que la collection reflète les éventuelles modifications qu'il y a eut (par un autre user par exemple)

qu'est-ce qui est le mieux niveau performance et volume de code ?
pour l'instant je recréé une collection à chaque tour, je compare cette collection avec la collection utilisée comme viewmodel et je fais les eventuelles modifs, ajout, suppression, ou modification d'une propriété, les clés ne changeant pas
pour l'instant je teste sur une classe avec deux propriétés donc ca se passe bien, mais y a t il une méthode plus adaptée à des grandes classes et des grands volumes de données ?

---

là j'avoue que je sais pas trop... j'ai pas encore été confronté à cette problématique

Citation:

---

mais comment faire pour synchroniser une base de données avec des collections ?

---

ça dépend pas mal de la base avec laquelle tu travailles et du niveau d'abstraction que tu veux.
La plupart des bases de données aujourd'hui sont capables d'envoyer des notifications quand il y a des modifications sur les données d'une table ("Continuous Query Notification" pour oracle par exemple, et peut-être "Notification Services" pour SQL server). Je ne connais pas les mécanismes offerts par d'autres SGBD, mais ça doit se faire aussi.

Sinon, en passant par des triggers sur update/insert, tu peux aussi mettre en place un mécanisme similaire.

Si plusieurs utilisateurs peuvent faire des modifs sur les données, la solution par timer qui va vérifier tous les x secondes me semble un peu hasardeuse, suivant le nombre d'utilsateurs, tu risques de tenter assez souvent de mettre à jour des données pas à jour.

oui y a les notifications de requete sur sql server (que j'utilise)
j'ai aussi pensé à un mécanisme pour connaitre les maj

je sais pas encore vers quoi je vais m'orienter les 2 n'étant ayant des inconvénients ...
m'enfin vérifier tous les tant de temps c'est pas mieux en effet ! ^^