Discussion: ouverture et fermture de connexion [Débutant]

  1. #1
    Membre habitué
    Homme Profil pro
    Autodidacte
    Inscrit en
    mars 2016
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Congo-Brazzaville

    Informations professionnelles :
    Activité : Autodidacte
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2016
    Messages : 104
    Points : 156
    Points
    156

    Par défaut ouverture et fermture de connexion

    Bonjour,
    je voudrai bien que comprendre dans le code suivant si je dois explicitement refermer la connexion ouverte et sinon quel est le risque encouru.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    public customers[] getcustomerbycity(int cityID)
            {
                var customerbycity = new List<customers>();
                var db = new easydatacontext();
                customerbycity = db.customers.Where(p => p.city_id == cityID).ToList();
     
                return customerbycity.ToArray();
     
            }
    Merci bien
    Prisson

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    609
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 609
    Points : 336
    Points
    336

    Par défaut

    Bonjour,

    En l'état c'est préférable. (ton contexte est déclaré localement)

    Tu peux placer ta variable de type easydatacontext à un endroit ou elle sera accessible de tous (EF gérera les accès concurrentiel)

    Si tu veux rester en usage local sache que le DbContext implémente IDisposable ainsi la bonne maniére de l'utiliser est d'utiliser un using

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public customers[] getcustomerbycity(int cityID)
    {
       List<customers> customerbycity;
     
       using(db = new easydatacontext())
       {
          customerbycity = db.customers.Where(p => p.city_id == cityID).ToList();
       }
     
       return customerbycity.ToArray();
    }

    et par piété arrêtez de mettre des "var" partout

    Ok quand c'est un type variable ou à super rallonge avec usage très ponctuel mais dans le reste des cas pensez à la lisibilité

  3. #3
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 352
    Points : 8 862
    Points
    8 862
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par TheBlackReverand Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    public customers[] getcustomerbycity(int cityID)
    {
       List<customers> customerbycity;
     
       using(db = new easydatacontext())
       {
          customerbycity = db.customers.Where(p => p.city_id == cityID).ToList();
       }
     
       return customerbycity.ToArray();
    }
    En effet, mais il ne faut pas oublier le .ToList(); car si on fait du lazy loading et que le context n'existe plus il va y avoir quelques soucis.


    Citation Envoyé par TheBlackReverand Voir le message
    et par piété arrêtez de mettre des "var" partout

    Ok quand c'est un type variable ou à super rallonge avec usage très ponctuel mais dans le reste des cas pensez à la lisibilité
    Ca c'est ton avis perso, si tu preferes coder "a l'ancienne" c'est ton choix mais il n'y a pas de mal a utiliser var.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige

  4. #4
    Rédacteur/Modérateur

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 420
    Points : 4 788
    Points
    4 788
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par Prisson
    sinon quel est le risque encouru.
    Les risques principaux sont :
    • consommation excessive de mémoire ;
    • risque de pénurie de connexion, notamment si le Pooling est activé.


    Au passage, convertir en List, puis en Array n'a pas de grande utilité ici. Autant convertir directement en Array. Et on peut aussi supprimer l'instanciation de la variable lors de sa déclaration, cela ne sert à rien ici. Cela diminuera légèrement la pression sur la mémoire.

    Citation Envoyé par DotNetMatt Voir le message
    Ca c'est ton avis perso, si tu preferes coder "a l'ancienne" c'est ton choix mais il n'y a pas de mal a utiliser var.
    Même s'il est entre guillemet ici, ce n'est pas la première fois que je vois le typage explicite désigné comme étant un codage "à l'ancienne". C'est, à mon sens, une position erronée. Ca fait maintenant 10 ans que C# a introduit le mot clé var.

    Pour ma part, je préfère également le type explicite. Je le trouve plus clair, plus facile à maintenir et force le développeur à réfléchir à son code. Par exemple, ai-je besoin que la variable que je manipule soit le type exacte ou simplement une interface ? Par exemple, pour les deux codes suivants, je trouve l'utilisation du typage explicite bien plus parlant pour le relecteur :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    var list = GetClientList();
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    IReadOnlyCollection<Client> list = GetClientList();
    Dans le premier cas, avec le mot clé var, ma liste sera typée en fonction du type de retour de la fonction GetClientList, soit par exemple, List<Client>.
    Dans le second cas, on précise exactement le besoin. Je n'ai pas besoin d'avoir une liste, juste une collection en lecture seule.

    Le relecteur a ainsi des informations supplémentaires sur la manière dont sera utilisée la variable list.

    Les seuls cas où personnellement j'utilise le mot clé var sont :
    • type long ou compliqué (généralement, des types génériques imbriqués, comme un dictionnaire de dictionnaire de liste) ;
    • type anonyme (courant avec les requêtes Linq).
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  5. #5
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 352
    Points : 8 862
    Points
    8 862
    Billets dans le blog
    3

    Par défaut

    C'est un debat, comme les gouts et les couleurs Je voulais juste souligner qu'il n'y a aucun mal a utiliser var. Apres bien sur il y a les cas ou il faut savoir ce que l'on fait (par ex. si on veut utiliser l'interface au lieu du type, comme tu l'as explique), mais si les membres de l'equipe sont eduques a la question, et si les tests unitaires sont correctement realises, il n'y a aucun probleme particulier ici.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige

  6. #6
    Rédacteur/Modérateur

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 420
    Points : 4 788
    Points
    4 788
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par DotNetMatt Voir le message
    C'est un debat,
    Tout à fait. Mais ce qui me gêne, c'est quand je lis que le typage explicite est un codage "à l'ancienne". Non, on parle de typage explicite ou implicite. Point. Sinon, on a l'impression que le type explicite est "has been", ce qui n'est absolument pas le cas. Il s'agit de deux approches différentes.

    mais si les membres de l'equipe sont eduques a la question, et si les tests unitaires sont correctement realises, il n'y a aucun probleme particulier ici.
    Bon, tu l'auras compris, on a deux avis différents sur l'utilisation de var ou pas Mais là, sans t'en rendre compte, en voulant défendre ton point de vue, tu tends une perche énorme pour la non utilisation de var Pour l'utiliser correctement, tu sous-entends qu'il faut :
    • que les équpes soient éduquées ;
    • que les tests unitaires soient bien fait.

    soit un énorme travail de pédagogie et de tests.

    Allez, pour montrer que je ne suis pas non plus complètement borné, je te donne un autre exemple où l'utilisation de var ne me gêne pas : dans une boucle foreach.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  7. #7
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 352
    Points : 8 862
    Points
    8 862
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par François DORIN Voir le message
    Tout à fait. Mais ce qui me gêne, c'est quand je lis que le typage explicite est un codage "à l'ancienne". Non, on parle de typage explicite ou implicite. Point. Sinon, on a l'impression que le type explicite est "has been", ce qui n'est absolument pas le cas. Il s'agit de deux approches différentes.
    Tu as raison Francois, je ferais plus attention aux mots que j'emploie a l'avenir

    Citation Envoyé par François DORIN Voir le message
    soit un énorme travail de pédagogie et de tests
    Ce n'est pas si enorme. Voici un peu plus de precisions. A l'embarquement des nouveaux, on prend des precautions. Les revues de code sont plus pointilleuses que normal, mais comme on utilise ReSharper (R#), les regles font pas mal de travail quasiment automatiquement, et les nouveaux ont juste a faire attention aux notifications de R#, ou bien a utiliser le correcteur automatique de R# pour que toutes les "erreurs" du fichier en cours soient corrigees. Ca a pris presque 1 an pour tout tuner correctement mais maintenant ca roule ! On a aussi develope des regles custom.

    Quand aux tests unitaires, j'ai remarque que la plupart du temps il y a des lacunes quoi qu'il arrive. On a donc mis en place une session obligatoire lors des premieres semaines pour les former aux tests unitaires et a ce qu'est l'injection de dependences. Ensuite on a dans notre framework de test des fonctions qui se chargent de reverifier certaines de nos regles (principalement qu'on utilise bien les interfaces et jamais - sauf exception - les implementations.

    Donc au final, on s'en sort pas si mal avec l'automatisation, meme si effectivement il y a un leger surcout au demarrage pour les nouvelles recrues et il a fallu un peu de temps pour mettre tout ca en place.

    Citation Envoyé par François DORIN Voir le message
    Allez, pour montrer que je ne suis pas non plus complètement borné, je te donne un autre exemple où l'utilisation de var ne me gêne pas : dans une boucle foreach.
    Haha sans rancune, j'accepte les differentes positions sur ce sujet Encore que dans un foreach ca peut etre trompeur quand on cherche a enumerer une collection custom (i.e. class MonType : IList<AutreTypeA>, et qu'on veut recuperer des objets qui heritent de class AutreTypeB : AutreTypeA Auquel cas il faut typer en AutreTypeB au lieu de var :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    foreach (AutreTypeB obj in monType)
    Sinon obj sera de type AutreTypeA.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige

  8. #8
    Rédacteur/Modérateur

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 420
    Points : 4 788
    Points
    4 788
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par DotNetMatt Voir le message
    Ce n'est pas si enorme. Voici un peu plus de precisions. A l'embarquement des nouveaux, on prend des precautions. Les revues de code sont plus pointilleuses que normal, mais comme on utilise ReSharper (R#), les regles font pas mal de travail quasiment automatiquement, et les nouveaux ont juste a faire attention aux notifications de R#, ou bien a utiliser le correcteur automatique de R# pour que toutes les "erreurs" du fichier en cours soient corrigees. Ca a pris presque 1 an pour tout tuner correctement mais maintenant ca roule ! On a aussi develope des regles custom.

    Quand aux tests unitaires, j'ai remarque que la plupart du temps il y a des lacunes quoi qu'il arrive. On a donc mis en place une session obligatoire lors des premieres semaines pour les former aux tests unitaires et a ce qu'est l'injection de dependences. Ensuite on a dans notre framework de test des fonctions qui se chargent de reverifier certaines de nos regles (principalement qu'on utilise bien les interfaces et jamais - sauf exception - les implementations.

    Donc au final, on s'en sort pas si mal avec l'automatisation, meme si effectivement il y a un leger surcout au demarrage pour les nouvelles recrues et il a fallu un peu de temps pour mettre tout ca en place.
    Dans un contexte général, cela n'a pas forcément un surcoût énorme à la vue des autres avantages en plus. Mais si on en revient un peu à la discussion initiale, tout cela "juste" pour utiliser le typage implicite au lieu de l'explicite, cela me parait disproportionné

    Citation Envoyé par DotNetMatt Voir le message
    Haha sans rancune, j'accepte les differentes positions sur ce sujet Encore que dans un foreach ca peut etre trompeur quand on cherche a enumerer une collection custom (i.e. class MonType : IList<AutreTypeA>, et qu'on veut recuperer des objets qui heritent de class AutreTypeB : AutreTypeA Auquel cas il faut typer en AutreTypeB au lieu de var :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    foreach (AutreTypeB obj in monType)
    Sinon obj sera de type AutreTypeA.
    Tout à fait, mais ça reste un cas particulier où on itère tout en castant un objet. En général, j'évite cela. Je préfère itérer d'abord, et caster ensuite en utilisant as. La différence ? En cas de cast impossible, je peux gérer plus finement les erreurs au cas par cas. Avec l'itération couplé au casting, dès la première erreur, la boucle prend fin.

    Après, dans la plupart des cas, quand on itère sur une collection, on itère quand même directement sur le type ^^ Le cas où on peut fréquemment utiliser l'itération couplé au casting reste, à mon avis, le cas spécifique de l'implémentation d'une couche métier, où on n'expose que des interfaces, mais où on a besoin d'accéder aux implémentations.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Ouverture propre d'une connexion SQL
    Par Anduriel dans le forum VB.NET
    Réponses: 2
    Dernier message: 25/10/2010, 01h28
  2. Connexion auto à l'ouverture explorateur fichier
    Par jlvalentin dans le forum Windows XP
    Réponses: 29
    Dernier message: 07/07/2006, 12h47
  3. [devcpp][winsock]Ouverture de port avec plusieurs connexions
    Par Belegkarnil dans le forum Dev-C++
    Réponses: 9
    Dernier message: 10/04/2006, 14h18
  4. Ouverture de connexion et envoi d'un message par socket
    Par loleske dans le forum C++Builder
    Réponses: 3
    Dernier message: 10/02/2005, 13h52
  5. [JNI] Ouverture connexion internet
    Par nebka dans le forum APIs
    Réponses: 2
    Dernier message: 06/08/2004, 15h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo