Quand créer un contexte de données Entity Framework dans une application ASP.NET ?

Question

Bonjour.

Dans une application ASP.NET, quand créer un contexte de données Entity Framework ?

• au démarrage de l'application, avec sauvegarde dans un objet Application, et chaque utilisateur utilise le même contexte ?
• au démarrage de chaque session, avec sauvegarde dans un objet Session ?
• à chaque transaction, avec donc effacement implicite au Unload ?

Je précise qu'aucune de mes transactions ne s'attend à retrouver quelque part des enregistrements lus lors d'une transaction précédente.

J'ai lu un livre de Julien Dollon et James Ravaille, Visual Studio 2010, qui propose de construire un dictionnaire statique de contextes (un par session id), mais je ne comprends pas les raisons de ce choix. De plus, une classe static/Shared ne disparaît-elle pas quand aucune transaction web n'est en cours d'exécution ?

Merci de votre aide,

Gilbert

Answer 1

Bonjour,

1 est à éliminer. Dans ce cas, le même contexte serait partagé par tous les utilisateurs ce qui entrainerait des problèmes si deux utilisateurs appelent une page (même différente) en même temps.

Reste 2 ou 3 (pour 2, le fait d'en avoir un par session est de bien s'assurer que chaque utilisateur dispose bien de son propre contexte).

Si je prends le principe de prendre la méthode la plus simple qui fonctionne, je dirais 3 jusqu'à avoir prouver que 2 apporte un avantage concret (temps d'instanciation du contexte ?).

En s'organisant un peu on doit pouvoir s'affranchir de ce point et pouvoir changer d'avis plus facilement (avec une fonction qui retourne un contexte, qu'il s'agisse d'un contexte nouvellement créé ou d'un contexte stocké en session ce qui permettra de changer l'architecture sous jacente plus facilement en cas de besoin).

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

Answer 2

Bonjour

Il semble que cette approche soit le bon compromis

using (MyLinqToEntities tonContext = new MyLinqToEntities())
{
    try
    {
       // ton code
    }
    catch (NotSupportedException ex)
    {
        // ton code
    }
}

La génération des query ne signifie pas que la base sera sollicitée lors de la construction de la requête car ce n'est qu'au bind() final des éléments que le framework génère l'ordre SQL et donc sollicité la base.

Le Framework gère aussi les accès concurrents donc pas de problème particulier à ce que chaque utilisateur ait son "propre" contexte (et je pense c'est plus souhaitable pour le traçage).

A près il est possible d'étendre les fonctionnalités en utilisant RIA Services (qui génèrera les classes de consultation et modification sur l'Entity Framework)

En espérant que cela vous aidera

Cordialement

E. Leite