Discussion :

[stailer]

Bonjour,

J'ai un problème, sur le Dispose d'Entities dans WCF.

En effet voici un code qui ne fonctionne pas, alors qu'avec ASP.NET par exemple j'ai aucun souci :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 public List<ARTICLE> GetArticlesByRubrique(ARTICLE_RUBRIQUE rub)
        {
            CMSEntities cnx = new CMSEntities();
                var query = from articles in cnx.ARTICLE
                            join rubriques in cnx.ARTICLE_RUBRIQUE on articles.idrubrique equals rubriques.idrubrique
                            where articles.is_deleted == false && rubriques.is_deleted == false
                            select articles;
 
                if (rub != null)
                    query = from articles in query where articles.idrubrique == rub.idrubrique select articles;
 
                return query.ToList();
        }

Si j'enlève le "using" et donc que je ne Dispose plus mon Entities , ça fonctionne impec.

Egalement, j'ai remarqué que sur d'autres requêtes, le fait de faire un "Detach" fonctionnait... Mais si ma requête comporte des jointures je les perds.

La solution serait donc bien sur de fabriquer des objets spécifiques avec le contenu exact de ce qu'attend Silverlight (jointures et tout ça) .. Je sais que ce serait aussi plus performant mais bon..

Peut-être que l'un d'entre vous à une solution simple à ce problème ?

En vous remerciant,

[Nathanael Marchand]

Bon deja y'a un truc que je comprends pas c'est la necessite de faire des jointures. Avec un edmx correctement modélisé (ie qui laisse apparaitre les jointures) tu n'en as pas besoin.

Typiquement un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
from articles in cnx.ARTICLE
where articles.is_deleted == false && articles.rubriques.is_deleted == false
select articles;

Ensuite, cela vient du fait qu'au moment de la sérialisation, il parcoure et sérialise tout ce qu'il peut. Du coup, il charge les collections dépendantes via Lazy Loading. Heureusement qu'il s'arrete de sérialiser à un moment (une profondeur qui peut se régler) car t'as de grandes chances de charger en mémoire toute ta base avec le problème des requêtes n+1.
Il faut donc empecher le Lazy Loading et provoquer un Eager Loading (via la directive Include())

[stailer]

Oui oui pour la jointure, elle n'y était pas en fait, c'est un résidu d'autres tests avec objets spéficiques.

Mise à part ça tu me dis que mon problème peut se résoudre par :

Il faut donc empecher le Lazy Loading et provoquer un Eager Loading (via la directive Include())

C'est à dire ?
Tu parles toujours de la jointure la ou tu parles de la solution pour réussir à implémenter le Using ?

[Nathanael Marchand]

En fait ce qui se passe:
Quand tu fais un using, le contexte n'existe que dans le using (logique). Or la sérialisation se passe en dehors du using et comme la sérialisation essaie de faire les lazy loadings alors que le contexte n'existe plus, ca coince!

La solution comme je le disais c'est soit le Eager Loading soit utiliser un contexte tout autour de la requête WCF (solution plus complexe mais beaucoup plus classe)

[stailer]

Ok, je connais pas du tout ce terme de : "Eager Loading".

Aurais-tu un exemple simple pour mettre ça en place ?

Ou alors un exemple avec ton "contexte" car la non plus je ne vois pas concrètement à quoi cela correspond.

Je te remerci pour l'intérêt que tu portes à ce post.

[Nathanael Marchand]

Un article assez complet sur le chargement de données (lazy vs eager vs explicit):
http://msdn.microsoft.com/en-us/library/bb896272.aspx

Pour ce qui est du contexte par requête c'est assez compliqué à mettre en place mais c'est THE solution. Tout dépend du reste de l'architecture mais grosso modo, dès qu'une requête WCF arrive on l'enrole dans un contexte Entity Framework. A la fin on effectue un commit si la requête a été concluante et on rollback en cas d'échec.
Ca suppose de mettre une infrastructure qui permet au lieu de créer un new CMSEntities() de récuperer une instance CMSEntities.CurrentInstance qui est un singleton par thread (chaque thread à le sien qui est différend des autres).

[stailer]

Ok, je crois que je vais me fabriquer directement des objets "spécifiques" qui donnent le résultat final attendu...

Partir sur une usine comme ça me parait compliqué.
Je comprends pas que Microsoft ne propose pas quelque chose de "fini" à ce niveau.

Merci pour ces explications en tous cas, je marque en résolu

[Nathanael Marchand]

Ah pour le coup, c'est juste que le lazy loading a toujours été un peu complexe à utiliser. Tu as le même problème avec NHibernate. D'après moi, il devrait être desactivé par défaut car si on ne le maitrise pas, on a vite fait d'avoir plein de problèmes (genre je remonte la moitié de la base ou le problèmes des requêtes n+1)

[stailer]

Bon quand même j'ai regardé les articles que tu m'as donné... Et finalement j'en suis arrivé à ceci qui fonctionne impec !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 using (CMSEntities cnx = new CMSEntities())
            {
                cnx.ContextOptions.LazyLoadingEnabled = false;
 
                var query = from articles in cnx.ARTICLE.Include("ARTICLE_RUBRIQUE")
                            where articles.is_deleted == false && articles.ARTICLE_RUBRIQUE.is_deleted == false
                            select articles;
 
                if (rub != null)
                    query = from articles in query where articles.idrubrique == rub.idrubrique select articles;
 
                return query.ToList();       
            }

Encore merci pour l'aide !