none
Dbcontext sous Entity Framework RRS feed

  • Question

  • Bonjour,

    Sur base d'un exemple MSDN, j'ai utilisé le code suivant quie est associé à un click d'un bouton:

    using (var contextPDT = newProduitContext()) { Produit pdt = new Produit();
    pdt.Name = "Produit1";
    ...
    contextPDT.Produits.Add(pdt);     int result = contextPDT.SaveChanges();     if (result == 1)     { //Opération Ok     } }

    Je voulais savoir, si ce n'est pas peu contraignant de faire un using en créant à chaque fois un DbContext pour chaque opération lié au click du bouton ? Y' a-t-il une autre manière plus optimale de procéder ?

    Merci d'avance.


    Beel

    lundi 17 novembre 2014 11:41

Réponses

  • Bonjour,

    Ha ce principe là, oui EF se charge de lui même de rendre la phase transfert de données la plus courte possible, a la lecture. Ensuite tant que vous n'appliquez pas les modifications avec .SaveChanges() il n'y a pas de communication avec la base de données.

    Cordialement,

    PS : marquer "Comme réponse" les posts qui ont répondu à la question.


    Yan Grenier

    • Marqué comme réponse beela mardi 18 novembre 2014 09:03
    mardi 18 novembre 2014 08:34
  • Bonjour,

    Je voulais en fait parler des deux modes supporté par Ado.Net (Connecté et Déconnecté) que j'ai trouvé en lisant la doc sur Ado.Net.

    Mais, maintenant, d'après ce que j'ai compris d'Entity Framework, je ne dois pas me préoccupé de gérer la connexion, cela est fait de manière implicite par EF.

    Merci à vous Yan Grenier pour les éléments de réponses qui m'ont été très utiles.

    Cordiales salutations.


    Beel

    • Marqué comme réponse beela mardi 18 novembre 2014 08:30
    mardi 18 novembre 2014 08:26
  • Bonjour,

    C'est vrai, vous avez bien fait de le mentionner. En effet, j'aurai du le préciser, c'est bien une application orienté multi connexions.

    Merci aussi Mathieu Notin pour cette précision fondamentale.

    Cordliales salutations.


    Beel

    • Marqué comme réponse beela mardi 18 novembre 2014 08:30
    mardi 18 novembre 2014 08:29

Toutes les réponses

  • Bonjour,

    Certes cela peu paraître un peu contraignant en terme d'écriture de code, mais c'est la méthode recommandée pour l'utilisation des connexions en ADO.NET (http://msdn.microsoft.com/en-us/library/ms254507(v=vs.100).aspx).

    D'un point de vue "optimisation", en réalité un DbContext utilise le pool de connexion de ADO.NET, donc lorsqu'on Dispose un contexte, la connexion n'est pas immédiatement terminée (sauf nécessité) et est réutilisée si un nouveau DbContext est créé (http://msdn.microsoft.com/en-us/library/bb399543(v=vs.100).aspx).

    Le principe d'utiliser le using permet également de faire le ménage dans la mémoire en cas d'exception (le using libérant les ressources quelle que soit la situation), ainsi on évite les risques de fuites de mémoire, ou les deadlocks sur le serveur parce qu'une requête est toujours "ouverte" et verrouille une table.

    Cordialement,


    Yan Grenier

    lundi 17 novembre 2014 13:20
  • Merci, pour votre réponse, bien claire.

    Donc, si j'ai bien compris. Il est possible d'avoir un Dbcontext persistant qui reste ouvert(si je peux m'exprimer ainsi) durant la durée de l'application, tant qu'il ne faut pas oublier de faire le dispose au bon moment pour libérer la mémoire ! Est-ce bien ça ?

    Sinon, je suppose que dans l'absolu, le fait d'utiliser un using à chaque opération reste une pratique courante même dans des applications professionnelles et ne va pas impacter les performances de l'application !

    Autre chose, si vous le permettez. Je suppose que c'est Entity Framework qui gère lui manière le mode connecté ou déconnecté ?

    Cordiales salutations.


    Beel

    lundi 17 novembre 2014 13:56
  • Oui vous pouvez instancier votre DbContext pour le maintenir, il se chargera de rouvrir la connexion si nécessaire. Mais ce n'est pas dans les bonnes pratiques d'utilisation de l'ADO.NET.

    Utiliser le using est non seulement une pratique courante, mais surtout la pratique recommandée par Microsoft, et son impact est négligeable au regard de la "sécurité/confort" de développement que cela procure : pour avoir gaspiller des heures à chercher les raisons d'un deadlock intempestif a cause d'une connexion non libérée j'applique religieusement cette recommandation :)

    Qu'est-ce que vous appelez le mode déconnecté ?

    Cordialement,


    Yan Grenier

    lundi 17 novembre 2014 16:31
  • Bonjour,

    Sur une appli client lourde, ca ne pose pas de souci outre mesure s'il n'y a qu'un user qui accède a la bdd à la fois. Il reste les problèmes d'optimisation comme expliqué par Yan.

    Par contre, dans le cas d'une appli multi connexion ou d'un site web, un dbcontext static ne fonctionnera pas du fait d'accès concurrents possibles.

    Cordialement,

    Mathieu


    Mathieu Notin

    lundi 17 novembre 2014 20:50
  • Bonjour,

    Je voulais en fait parler des deux modes supporté par Ado.Net (Connecté et Déconnecté) que j'ai trouvé en lisant la doc sur Ado.Net.

    Mais, maintenant, d'après ce que j'ai compris d'Entity Framework, je ne dois pas me préoccupé de gérer la connexion, cela est fait de manière implicite par EF.

    Merci à vous Yan Grenier pour les éléments de réponses qui m'ont été très utiles.

    Cordiales salutations.


    Beel

    • Marqué comme réponse beela mardi 18 novembre 2014 08:30
    mardi 18 novembre 2014 08:26
  • Bonjour,

    C'est vrai, vous avez bien fait de le mentionner. En effet, j'aurai du le préciser, c'est bien une application orienté multi connexions.

    Merci aussi Mathieu Notin pour cette précision fondamentale.

    Cordliales salutations.


    Beel

    • Marqué comme réponse beela mardi 18 novembre 2014 08:30
    mardi 18 novembre 2014 08:29
  • Bonjour,

    Ha ce principe là, oui EF se charge de lui même de rendre la phase transfert de données la plus courte possible, a la lecture. Ensuite tant que vous n'appliquez pas les modifications avec .SaveChanges() il n'y a pas de communication avec la base de données.

    Cordialement,

    PS : marquer "Comme réponse" les posts qui ont répondu à la question.


    Yan Grenier

    • Marqué comme réponse beela mardi 18 novembre 2014 09:03
    mardi 18 novembre 2014 08:34
  • Ok. Merci.

    Beel

    mardi 18 novembre 2014 09:03