Salut à vous.

Le binding de wpf offre la possibilité de charger de manière asynchrone sur un thread différent de celui de l'interface à l'aide de la propriété IsAsync.

Je sais que ObjectContext d'entity framework n'est pas threadsafe et que de ce fait, le lazy loading d'une propriété de navigation depuis un thread différent de celui du context n'est pas garantit.

Mais cela ne doit pas servir d'excuse pour bloquer complètement l'application à la moindre coupure réseau. C'est pourquoi je recherche des bonnes pratiques pour garder mon interface réactive.

La solution qui me vient à l'esprit et d'oublier le lazy loading, on m'a vendu ça comme un truc magique mais si tu comptes la dessus dans une interfaces graphique, tu peux te gratter pour libérer automatiquement ton contexte en encapsulant tes requêtes dans un using et bonne chance pour pas en oublier. Je pense donc à tout simplement instancier un nouveau contexte pour charger une propriété de navigation dans mes VM. MS encourage à spliter les context, mais cela impacte t'il vraiment que peu les performances de l'application ?

Merci à vous.

Edit:

Après réflexion, c'est un gros problème d'architecture de laisser vivre les entités dans la couche de la vue. Je vais laisser mes repository se charger du tracking des modifications et couper complètement le cordon avec entity-framework au niveau de la vue.