Discussion :

[Colbix]

Rebonjour à tous ,

J'ai de nouveau un problème. Pour commencer, voici mon code :

Study Controller (Couche GUI) :

Code :

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

1
2
3
4
5
ViewResult Index(string search)
        {
            var studies = StudyManager.SelectAll();
            return View(studies);
        }

Study Manager (Couche BLL) :

Code :

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

1
2
3
4
public static List<Study> SelectAll()
        {
            return StudyRep.Select();
        }

Study Repository (Couche DAL) :

Code :

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

1
2
3
4
5
6
7
public static ICollection<Study> Select()
        {
            using (PrismaDAL dal = new PrismaDAL())
            {
                return dal.Studies.ToList();
            }
        }

On voit que le Repository des Studies se crée un contexte pour charger la liste complète des studies.
Le souci est que dans ma vue, j'aimerai accéder à un sous objet (une Phase) de chaque étude de la liste :

Code :

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

1
2
3
4
@if (Model.Phase != null)
{
    @Html.ActionLink(Model.Phase.Label, "Details/" + Model.Phase.Id.ToString(), "Codelist")
}

Au moment ou ma vue est exécutée, le contexte est déjà détruit et le lazy-loading est donc impossible.

Ma question :
Comment faire pour que mon sous-objet soit accessible ? Comment avoir un contexte qui "vit" assez longtemps pour permettre le lazy-loading dans la vue.

Je me suis renseigné avant de poster évidemment, voici les solutions possibles :
- Créer le context dans le controller, mais la division en couche n'est pas respectée.
- Une autre option (qui est plus conseillée) est d'avoir un contexte par requete. En chipotant dans le global.asax, ca semble possible, mais je n'y arrive pas... Comment faire ?

A+ et merci bcp

[Nathanael Marchand]

Le Eager Loading est préférable

Code :

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

1
2
3
4
5
6
7
public static ICollection<Study> Select()
{
    using (PrismaDAL dal = new PrismaDAL())
    {
        return dal.Studies.Include("Phase").ToList();
     }
}

[Colbix]

Salut,

Merci pour ta réponse . Par contre ta solution implique que la couche GUI connaisse la couche DAL. La division en couche n'est donc pas respectée.

Normalement, la couche GUI ne devrait appeler que la couche BLL :

Code :

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

1
2
3
GUI > BLL > DAL
   \   |   /
       BO

Si tu as une autre idée, n'hésite pas .

A+

[Nathanael Marchand]

Euh ben non, c'était une méthode pour ta DAL que je t'ai proposé.

[Colbix]

Salut,

Oups, j'avais pas vu le " Include("Phase") ".

Le problème ici, c'est qu'on perd la simplicité d'utilisation du lazy-load. De plus, "Phase" était un exemple, ma structure est beaucoup plus complexe et un objet study est composé d'un grand nombre d'autres objets (dont phase).


J'ai trouvé un moyen pour que le contexte ne soit détruit qu'à la fin de la requête :
Global.asax (Couche GUI) :

Code :

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

1
2
3
4
protected void Application_EndRequest()
        {
            PrismaBLL.initializeContext();
        }

PrismaBLL (couche BLL) :

Code :

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

1
2
3
4
public static void initializeContext()
        {
            PrismaDAL.RemoveContext();
        }

PrismaDAL (Couche DAL) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class PrismaDAL : DbContext
    {
        private static PrismaDAL _instance = null;
        public static PrismaDAL Instance
        { 
            get
            {
                if (_instance == null)
                    _instance = new PrismaDAL();
                return _instance;
            }
        }
 
        public static void RemoveContext()
        {
            if (_instance != null)
                _instance.Dispose(true);
            _instance = null;
        }
 
        public DbSet<Codelist> Codelists { get; set; }
        public DbSet<Study> Studies { get; set; }
    }

En faisant du contexte un singleton réinitialisé à la fin de chaque requête, ca passe parfois, mais dans certains cas, j'ai toujours mon problème :'(.

Ouiiin ! Que faire ?


Merci pour ton aide

[Nathanael Marchand]

Dans l'idéal c'est effectivement ce qu'il faudrait faire: un contexte par requête. Par contre attention à ton cas: deux requêtes simultanées partageraient le contexte!
Malhereusement, tu n'as pas trop le choix dans ton cas. Le lazy-loading c'est un truc qui peut être pratique mais qui peut s'avérer finalement très complexe à utiliser correctement et très dangereux sur les perfs (problème des requêtes n+1 par exemple).
Ce que je conseille/ferais c'est de ne pas présenter les entités EF mais créer un objet de présentation qui ressemble à mon entité et le remplir avec plusieurs requêtes.
D'une manière générale, le lazy-loading dans l'interface utilisateur n'est pas une bonne idée.

[tomlev]

Par contre attention à ton cas: deux requêtes simultanées partageraient le contexte!

Effectivement... une solution simple serait de rendre ThreadStatic le champ _instance. Comme ça chaque thread (et donc chaque requête simultanée) aurait sa propre instance du DbContext.

Code :

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

1
2
[ThreadStatic]
private static PrismaDAL _instance = null;

[neoncyber]

Déjà pour avoir un faible couplage / une couche anticorruption, il est préferable de passer par le system de DTO entre tes couches. (automapper est ton amis).
Comme ca le jour au ta besoin de rajouter une couche entre les deux (comme une couche service) ba pas de problème.
Enfin c'est pas obligé.
C'est sur le lazy loading est réservé a la class qui utilise ton repository, mais avec ASP MVC 3 tu peu faire de l'IOC dans tes vues, dans ce context (ce n'est pas la bonne maniere de faire si tu ne veux pas de dépendance entity/Gui) tu peu initializer ton repository directement dans le vue, et tappé dans ta DAL uniquement a l'aide de l'interface de ta BLL ITrucMuchRepository (grace a IOC). Par contre la c'est la methode sans DTO.

IOC pour les vues :
http://bradwilson.typepad.com/blog/2...pt3-views.html

[Colbix]

Salut à tous,

Merci pour ces conseils . Je vais donc utiliser les DTOs entre la couche GUI et BLL. Ca demande une bonne refonte du code, mais c'est pour la bonne cause .

Pour rendre mon signleton thread-safe, j'ai rajouté un lock comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class PrismaDAL : DbContext
    {
        private static PrismaDAL _instance = null;
        static readonly object _instanceLock = new object();
        public static PrismaDAL Instance
        { 
            get
            {
                lock (_instanceLock)
                {
                    if (_instance == null)
                        _instance = new PrismaDAL();
                    return _instance;
                }
            }
        }
 
        public static void RemoveContext()
        {
            if (_instance != null)
                _instance.Dispose(true);
            _instance = null;
        }
 
        private PrismaDAL()
        {
        }
 
        public DbSet<Codelist> Codelists { get; set; }
        public DbSet<Study> Studies { get; set; }
    }

Vous en pensez-quoi ? C'est risqué pour un grand nombre d'utilisateur ?

Merci beaucoup .

[Nathanael Marchand]

Ben ca empeche que deux threads distincts crééent en même temps un contexte mais ca mutualise quand même ton instance à tous les threads.

[neoncyber]

Ba si tu passe par des DTOs et la methode qui consiste a les chargers dans ta BLL, je te conseil de laisser beton le singleton pour le dbcontext vue que tu na plus de problème.
Apparement si tu veux pas le regretter un jour faut mieu eviter le singleton de DbContext
http://www.britishdeveloper.co.uk/20...ts-entity.html
En plus en ASP.Net la notion de singleton est bien pourri (contrairement a du C++), en effet le singleton est unifier a l'ensemble des visiteur/utilisateur de ton site web.

[Colbix]

Hmm,

C'est pas super si on espère avoir beaucoup de monde sur le site...
Comme dit ci-dessus, il faudrait créer un contexte par requête.

On aurait donc un code semblable à ceci :
Dans le global.asax :

Code :

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

1
2
3
4
5
6
7
8
9
protected void Application_BeginRequest()
        {
            _dal = new PrismaDAL();
        }
 
        protected void Application_EndRequest()
        {
            _dal.dispose;
        }

Et dans mes repositories, comment récupérer ce Contexte tout fraîchement créé ?

Encore et toujours un grand merci pour votre aide .

[tomlev]

Bah non tu peux pas faire comme ça... l'objet Global est global à l'application (comme son nom l'indique), donc les requêtes simultanées vont se marcher sur les pieds. Mets plutôt ton DbContext dans le contexte de la requête (HttpContext.Current)

[neoncyber]

Perso je ferrai pas comme tu fait, mais plutot comme tous les autre fond, moi compris,

Solution "Standard" casse pied pour les jointures :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class HomeController : Controller
{
     [Dependency]
     public IPhaseRepository repository {get; set;}
 
 
     public ActionResult Index()
     {
           return View(repository.ToList());
     }
}

Solution Proxy/partage du context entre repository:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public class HomeController : Controller
{
     [Dependency]
     public IRepository repository {get; set;}
 
 
     public ActionResult Index()
     {
           return View(repository.Phase.ToList());
     }
}

Ou dans ta BLL :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class MyBll : IMyBll
{
     [Dependency]
     public IRepository repository {get; set;}
 
 
     public List<PhaseDto> Index()
     {
           return repository.Phase.ToDto());
     }
}

Ici chaque class qui porte le nom repository a sa propre instance de dbcontext, et ne la partage pas avec l'exterieur.

[Colbix]

Bah non tu peux pas faire comme ça... l'objet Global est global à l'application (comme son nom l'indique), donc les requêtes simultanées vont se marcher sur les pieds. Mets plutôt ton DbContext dans le contexte de la requête (HttpContext.Current)

C'est une manière courante de faire ?
Si oui, ça ressemblerais à quoi en code ?

Merci

[tomlev]

C'est une manière courante de faire ?

Aucune idée... je fais très peu de développement web, donc je saurais pas dire si c'est une pratique répandue (ni si c'est une bonne pratique d'ailleurs...)

Si oui, ça ressemblerais à quoi en code ?

Code :

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

1
2
3
4
5
6
7
8
9
10
        protected void Application_BeginRequest()
        {
            HttpContext.Current.Items["dal"] = new PrismaDAL();
        }
 
        protected void Application_EndRequest()
        {
            var dal = (PrismaDAL)HttpContext.Current.Items["DAL"];
            dal.Dispose();
        }