Discussion :

[anthyme]

Bonjour,

Je pense que j'aborde une des limitations les plus embêtante de linq to sql : utiliser une entity dans un DataContext provenant d'un autre DataContext.

J'ai pas mal fouiller le net et j'y ai vu un peu de tout et n'importe quoi ... (d'un point de vue conception pas fonctionnel).

En effet pour signaler que vous avez édité une entity ailleurs que dans votre context il faut l'attacher au datacontext via la méthod Attach(entity,true). Sauf que dans certain cas on a des NotSupported exception du au fait que votre objet a été créé dans un autre DataContext.

Dans certains cas on peut mettre les DataContext à ObjectTrackingEnabled = false;
et ces entités sont réutilisable dans d'autre dans d'autre datacontext.
Sauf que cette option n'est utilisable que dans le cas ou l'on fait du select (et pas du insert/update) donc si j'ai un objet de type Person qui est lié a un objet Address que je veux mettre a jour et bien je vais d'abords attacher mon objet entity et lui préciser de le mettre a jour dans un datacontext puis au moment je vais tenter de faire la même chose dans un autre datacontext pour l'objet address et bien je ne pourrais pas car il aura été rattaché au précédant datacontext.

J'ai vu pas mal de solution sur le net, des gens qui copie leur objet a la main (j'ai réussi mais qu'est ce que c'est peu maintenable et lourd) ou le serialize en XML (hélas j'ai un champ timestamp System.Data.Linq.Binary qui ne veux pas se sérialiser ou alors j'utillise surement pas le bon serializer car les objet passe bien dans WCF ... CF mon topic dans le forum WCF) ou encore d'autre personne qui utilise la méthode Refresh du datacontext (pas réussi à l'utiliser celle la).

Bref c'est vraiment lourd quand même ...

Donc voila pour ceux qui pratique j'aimerai bien savoir comment vous réglez ce genre de problèmes ?

Merci

[anthyme]

bon bin au final je met un context plus "persistant"