Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
Non pas besoin
Il y a quelques debats sur le net a ce propos (pas pour des strings je te
rassure) donc en regle generale: non pas besoin
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
C'est legitime de penser a faire cela, mais le garbage collector se charge
de verifier l'arboresence des references:
Si ta classe n'est plus referencee nulle part, tous les objets uniquement
lies a ta classe seront eligibles au nettoyage
(il FAUT que tu lises les articles des liens que j'ai mis tt en bas)
> 3)
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
Non pas besoin
Il y a quelques debats sur le net a ce propos (pas pour des strings je te
rassure) donc en regle generale: non pas besoin
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
C'est legitime de penser a faire cela, mais le garbage collector se charge
de verifier l'arboresence des references:
Si ta classe n'est plus referencee nulle part, tous les objets uniquement
lies a ta classe seront eligibles au nettoyage
(il FAUT que tu lises les articles des liens que j'ai mis tt en bas)
> 3)
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
Non pas besoin
Il y a quelques debats sur le net a ce propos (pas pour des strings je te
rassure) donc en regle generale: non pas besoin
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
C'est legitime de penser a faire cela, mais le garbage collector se charge
de verifier l'arboresence des references:
Si ta classe n'est plus referencee nulle part, tous les objets uniquement
lies a ta classe seront eligibles au nettoyage
(il FAUT que tu lises les articles des liens que j'ai mis tt en bas)
> 3)
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
Merci à tous
Johnny
(*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
(**) Avez-vous un (bon) lien à ce sujet ?
//---------------------------------------
//--------------------------------------- Portion de code
//---------------------------------------
public void Dispose()
{
this.Dispose( true );
GC.SuppressFinalize( this );
}
public void Dispose( bool disposing )
{
if( disposing )
{
// Suppression des objets managés
}
// Suppression des objets non managés
}
~MaClasse()
{
this.Dispose( false );
}
Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
Merci à tous
Johnny
(*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
(**) Avez-vous un (bon) lien à ce sujet ?
//---------------------------------------
//--------------------------------------- Portion de code
//---------------------------------------
public void Dispose()
{
this.Dispose( true );
GC.SuppressFinalize( this );
}
public void Dispose( bool disposing )
{
if( disposing )
{
// Suppression des objets managés
}
// Suppression des objets non managés
}
~MaClasse()
{
this.Dispose( false );
}
Bonjour ou bonsoir,
Je crée une classe MaClasse implémentant l'interface IDisposable.
Vous trouverez (sans entrer dans le détail) l'allure de mon code à la fin
mon message.
Je me pose quelques questions au sujet du contenu de la méthode public
Dispose( bool disposing )
1) Ma classe contient quelques variables private de type string. Est-ce
qu'il y a un intéret à faire un this.maVariableString = null; ?
2) D'une manière générale, j'envisage de mettre à null tous les objets,
managés ou non, et d'appeller au préalable la methode .Dispose() si et
seulement si l'objet a été crée par la classe ( et bien entendu si l'objet
"nullifier" propose la méthode Dispose() (*) ).
3) MaClasse travaille avec une base de données et possède une donnée
de type IDbConnection. Cet objet de type IDbConnection est un argument
constructeur; il est aussi accessible en lecture/écriture (get/set) via
propriété. J'envisage donc, dans mon Dispose, de faire un simple
this.MonIdbConnection = null;. Je n'envisage rien d'autre, en particulier
aucun appel à un .Close() ou un .Dispose() car la connexion est partagée :
l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion au
constructeur de MaClasse, afin de profiter d'une connexion ouverte et donc
de faire l'économie d'une connexion supplémentaire... Est-ce là une bonne
pratique ? Je pose la question car j'ai lu, içi ou là dans quelques posts,
qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
est efficace et général, je pourrais alors passer plutôt par une chaine de
connexion, et créer une nouvelle connexion réellement propre à MaClasse,
puis fermer la conenxion dans le Dispose(), et par exemple ne pas supposer
ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin dans
MaClasse...
4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
objet implémente une interface (réflexion) ?
Merci à tous
Johnny
(*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
(**) Avez-vous un (bon) lien à ce sujet ?
//---------------------------------------
//--------------------------------------- Portion de code
//---------------------------------------
public void Dispose()
{
this.Dispose( true );
GC.SuppressFinalize( this );
}
public void Dispose( bool disposing )
{
if( disposing )
{
// Suppression des objets managés
}
// Suppression des objets non managés
}
~MaClasse()
{
this.Dispose( false );
}
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
Bonjour,
Voici quelques règles générales à suivre :
1. Le code .NET (indépendemment du langage) est managé = fini les "je
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
à rien.
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
d'être conservés ouverts (connexions de base de données, fichiers, etc, 2)
libérer les ressources non managés (références à des objets COM, etc).
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
5. En C#, utilisez le mot clé using (...) {..} pour appeler implicitement
les méthodes Dispose(). Ca évite d'oublier.
Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
Using Destructors to Release Resources
In general, you should NOT be as concerned about memory management as you
would with C++. This is because the .NET Framework garbage collector
implicitly manages the allocation and release of memory for your objects.
However, when your application encapsulates UNMANAGED resources such as
windows, files, and network connections, you should use destructors to
those resources. When the object is eligible for destruction, the garbage
collector runs the object's Finalize method.
Etes-vous dans le cas d'utilisation de ressources non managés ? Il semble
que non.
Tester si une interface est implémentée (C#):
IMonInterface o = obj as IMonInterface
if (o!=null)
{
// o implémente IMonInterface
}
Pascal Mercier
Microsoft France - MCS
"Johnny" wrote in message
news:4159c0e9$0$2232$
> Bonjour ou bonsoir,
>
> Je crée une classe MaClasse implémentant l'interface IDisposable.
> Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
de
> mon message.
> Je me pose quelques questions au sujet du contenu de la méthode public
void
> Dispose( bool disposing )
>
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
>
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
>
> 3) MaClasse travaille avec une base de données et possède une donnée
private
> de type IDbConnection. Cet objet de type IDbConnection est un argument
d'un
> constructeur; il est aussi accessible en lecture/écriture (get/set) via
une
> propriété. J'envisage donc, dans mon Dispose, de faire un simple
> this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
> aucun appel à un .Close() ou un .Dispose() car la connexion est partagée
> l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
objet
> MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
autre
> objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion
> constructeur de MaClasse, afin de profiter d'une connexion ouverte et
> de faire l'économie d'une connexion supplémentaire... Est-ce là une
> pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
> qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
mécanisme
> est efficace et général, je pourrais alors passer plutôt par une chaine
> connexion, et créer une nouvelle connexion réellement propre à MaClasse,
> puis fermer la conenxion dans le Dispose(), et par exemple ne pas
> ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
> MaClasse...
>
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
>
> Merci à tous
>
> Johnny
>
> (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> (**) Avez-vous un (bon) lien à ce sujet ?
>
> //---------------------------------------
> //--------------------------------------- Portion de code
> //---------------------------------------
>
> public void Dispose()
> {
> this.Dispose( true );
> GC.SuppressFinalize( this );
> }
>
> public void Dispose( bool disposing )
> {
> if( disposing )
> {
> // Suppression des objets managés
> }
> // Suppression des objets non managés
> }
>
> ~MaClasse()
> {
> this.Dispose( false );
> }
>
>
>
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
Bonjour,
Voici quelques règles générales à suivre :
1. Le code .NET (indépendemment du langage) est managé = fini les "je
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
à rien.
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
d'être conservés ouverts (connexions de base de données, fichiers, etc, 2)
libérer les ressources non managés (références à des objets COM, etc).
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
5. En C#, utilisez le mot clé using (...) {..} pour appeler implicitement
les méthodes Dispose(). Ca évite d'oublier.
Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
Using Destructors to Release Resources
In general, you should NOT be as concerned about memory management as you
would with C++. This is because the .NET Framework garbage collector
implicitly manages the allocation and release of memory for your objects.
However, when your application encapsulates UNMANAGED resources such as
windows, files, and network connections, you should use destructors to
those resources. When the object is eligible for destruction, the garbage
collector runs the object's Finalize method.
Etes-vous dans le cas d'utilisation de ressources non managés ? Il semble
que non.
Tester si une interface est implémentée (C#):
IMonInterface o = obj as IMonInterface
if (o!=null)
{
// o implémente IMonInterface
}
Pascal Mercier
Microsoft France - MCS
"Johnny" <Johnny@antispam.fr> wrote in message
news:4159c0e9$0$2232$626a14ce@news.free.fr...
> Bonjour ou bonsoir,
>
> Je crée une classe MaClasse implémentant l'interface IDisposable.
> Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
de
> mon message.
> Je me pose quelques questions au sujet du contenu de la méthode public
void
> Dispose( bool disposing )
>
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
>
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
>
> 3) MaClasse travaille avec une base de données et possède une donnée
private
> de type IDbConnection. Cet objet de type IDbConnection est un argument
d'un
> constructeur; il est aussi accessible en lecture/écriture (get/set) via
une
> propriété. J'envisage donc, dans mon Dispose, de faire un simple
> this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
> aucun appel à un .Close() ou un .Dispose() car la connexion est partagée
> l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
objet
> MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
autre
> objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion
> constructeur de MaClasse, afin de profiter d'une connexion ouverte et
> de faire l'économie d'une connexion supplémentaire... Est-ce là une
> pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
> qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
mécanisme
> est efficace et général, je pourrais alors passer plutôt par une chaine
> connexion, et créer une nouvelle connexion réellement propre à MaClasse,
> puis fermer la conenxion dans le Dispose(), et par exemple ne pas
> ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
> MaClasse...
>
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
>
> Merci à tous
>
> Johnny
>
> (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> (**) Avez-vous un (bon) lien à ce sujet ?
>
> //---------------------------------------
> //--------------------------------------- Portion de code
> //---------------------------------------
>
> public void Dispose()
> {
> this.Dispose( true );
> GC.SuppressFinalize( this );
> }
>
> public void Dispose( bool disposing )
> {
> if( disposing )
> {
> // Suppression des objets managés
> }
> // Suppression des objets non managés
> }
>
> ~MaClasse()
> {
> this.Dispose( false );
> }
>
>
>
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
Bonjour,
Voici quelques règles générales à suivre :
1. Le code .NET (indépendemment du langage) est managé = fini les "je
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
à rien.
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
d'être conservés ouverts (connexions de base de données, fichiers, etc, 2)
libérer les ressources non managés (références à des objets COM, etc).
4. Ouvrir les connexions aux bases de données le plus tard possible et les
refermer le plus tôt dès que possible. En clair, une connexion ne devrait
pas avoir une durée de vie qui va au delà de la méthode. Le connexion pool
est là pour la performance.
5. En C#, utilisez le mot clé using (...) {..} pour appeler implicitement
les méthodes Dispose(). Ca évite d'oublier.
Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
Using Destructors to Release Resources
In general, you should NOT be as concerned about memory management as you
would with C++. This is because the .NET Framework garbage collector
implicitly manages the allocation and release of memory for your objects.
However, when your application encapsulates UNMANAGED resources such as
windows, files, and network connections, you should use destructors to
those resources. When the object is eligible for destruction, the garbage
collector runs the object's Finalize method.
Etes-vous dans le cas d'utilisation de ressources non managés ? Il semble
que non.
Tester si une interface est implémentée (C#):
IMonInterface o = obj as IMonInterface
if (o!=null)
{
// o implémente IMonInterface
}
Pascal Mercier
Microsoft France - MCS
"Johnny" wrote in message
news:4159c0e9$0$2232$
> Bonjour ou bonsoir,
>
> Je crée une classe MaClasse implémentant l'interface IDisposable.
> Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
de
> mon message.
> Je me pose quelques questions au sujet du contenu de la méthode public
void
> Dispose( bool disposing )
>
> 1) Ma classe contient quelques variables private de type string. Est-ce
> qu'il y a un intéret à faire un this.maVariableString = null; ?
>
> 2) D'une manière générale, j'envisage de mettre à null tous les objets,
> managés ou non, et d'appeller au préalable la methode .Dispose() si et
> seulement si l'objet a été crée par la classe ( et bien entendu si
à
> "nullifier" propose la méthode Dispose() (*) ).
>
> 3) MaClasse travaille avec une base de données et possède une donnée
private
> de type IDbConnection. Cet objet de type IDbConnection est un argument
d'un
> constructeur; il est aussi accessible en lecture/écriture (get/set) via
une
> propriété. J'envisage donc, dans mon Dispose, de faire un simple
> this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
> aucun appel à un .Close() ou un .Dispose() car la connexion est partagée
> l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
objet
> MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
autre
> objet "pointe" déjà une base et est "ouvert". Je passe donc MaConnexion
> constructeur de MaClasse, afin de profiter d'une connexion ouverte et
> de faire l'économie d'une connexion supplémentaire... Est-ce là une
> pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
> qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
mécanisme
> est efficace et général, je pourrais alors passer plutôt par une chaine
> connexion, et créer une nouvelle connexion réellement propre à MaClasse,
> puis fermer la conenxion dans le Dispose(), et par exemple ne pas
> ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
> MaClasse...
>
> 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier si
un
> objet implémente une interface (réflexion) ?
>
> Merci à tous
>
> Johnny
>
> (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> (**) Avez-vous un (bon) lien à ce sujet ?
>
> //---------------------------------------
> //--------------------------------------- Portion de code
> //---------------------------------------
>
> public void Dispose()
> {
> this.Dispose( true );
> GC.SuppressFinalize( this );
> }
>
> public void Dispose( bool disposing )
> {
> if( disposing )
> {
> // Suppression des objets managés
> }
> // Suppression des objets non managés
> }
>
> ~MaClasse()
> {
> this.Dispose( false );
> }
>
>
>
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti de
l'exécution exacte de la méthode. Encore une fois le GC (Garbage
s'occupe pour vous de détruire l'objet.
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
à rien.
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
à rien.
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
à rien.
Bonjour,
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
Qu'est ce que vous entendez par éxécution "exacte" ?
Il est garanti que le destructeur/la méthode Finalize sera exécute à moins
qu'il n'ait été explicitement demandé que ce ne soit pas le cas par un
GC.SuppressFinalize().
De plus, un destructeur ne sert pas à détruire l'objet, donc même si le GC
détruit l'objet, ça n'empêche pas que la présence d'un destructeur soit
indispensable dans certains cas.
--
Zazar
Bonjour,
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
Qu'est ce que vous entendez par éxécution "exacte" ?
Il est garanti que le destructeur/la méthode Finalize sera exécute à moins
qu'il n'ait été explicitement demandé que ce ne soit pas le cas par un
GC.SuppressFinalize().
De plus, un destructeur ne sert pas à détruire l'objet, donc même si le GC
détruit l'objet, ça n'empêche pas que la présence d'un destructeur soit
indispensable dans certains cas.
--
Zazar
Bonjour,
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
Qu'est ce que vous entendez par éxécution "exacte" ?
Il est garanti que le destructeur/la méthode Finalize sera exécute à moins
qu'il n'ait été explicitement demandé que ce ne soit pas le cas par un
GC.SuppressFinalize().
De plus, un destructeur ne sert pas à détruire l'objet, donc même si le GC
détruit l'objet, ça n'empêche pas que la présence d'un destructeur soit
indispensable dans certains cas.
--
Zazar
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
[1] http://www.c-sharpcorner.com/Code/2004/May/PoolingNS.asp
"Pascal Mercier" a écrit dans le message
news:%23np$R$
> Bonjour,
>
> Voici quelques règles générales à suivre :
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
> les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
> à rien.
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
> 3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
> d'être conservés ouverts (connexions de base de données, fichiers, etc,
> libérer les ressources non managés (références à des objets COM, etc).
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
> 5. En C#, utilisez le mot clé using (...) {..} pour appeler
> les méthodes Dispose(). Ca évite d'oublier.
>
> Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
1.1:
> Using Destructors to Release Resources
> In general, you should NOT be as concerned about memory management as
> would with C++. This is because the .NET Framework garbage collector
> implicitly manages the allocation and release of memory for your
> However, when your application encapsulates UNMANAGED resources such as
> windows, files, and network connections, you should use destructors to
free
> those resources. When the object is eligible for destruction, the
> collector runs the object's Finalize method.
>
> Etes-vous dans le cas d'utilisation de ressources non managés ? Il
> que non.
>
> Tester si une interface est implémentée (C#):
> IMonInterface o = obj as IMonInterface
> if (o!=null)
> {
> // o implémente IMonInterface
> }
>
> Pascal Mercier
> Microsoft France - MCS
>
> "Johnny" wrote in message
> news:4159c0e9$0$2232$
> > Bonjour ou bonsoir,
> >
> > Je crée une classe MaClasse implémentant l'interface IDisposable.
> > Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
fin
> de
> > mon message.
> > Je me pose quelques questions au sujet du contenu de la méthode public
> void
> > Dispose( bool disposing )
> >
> > 1) Ma classe contient quelques variables private de type string.
> > qu'il y a un intéret à faire un this.maVariableString = null; ?
> >
> > 2) D'une manière générale, j'envisage de mettre à null tous les
> > managés ou non, et d'appeller au préalable la methode .Dispose() si et
> > seulement si l'objet a été crée par la classe ( et bien entendu si
l'objet
> à
> > "nullifier" propose la méthode Dispose() (*) ).
> >
> > 3) MaClasse travaille avec une base de données et possède une donnée
> private
> > de type IDbConnection. Cet objet de type IDbConnection est un argument
> d'un
> > constructeur; il est aussi accessible en lecture/écriture (get/set)
> une
> > propriété. J'envisage donc, dans mon Dispose, de faire un simple
> > this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
particulier
> > aucun appel à un .Close() ou un .Dispose() car la connexion est
:
> > l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
> objet
> > MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
> autre
> > objet "pointe" déjà une base et est "ouvert". Je passe donc
au
> > constructeur de MaClasse, afin de profiter d'une connexion ouverte et
donc
> > de faire l'économie d'une connexion supplémentaire... Est-ce là une
bonne
> > pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
posts,
> > qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
> mécanisme
> > est efficace et général, je pourrais alors passer plutôt par une
de
> > connexion, et créer une nouvelle connexion réellement propre à
> > puis fermer la conenxion dans le Dispose(), et par exemple ne pas
supposer
> > ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
dans
> > MaClasse...
> >
> > 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier
> un
> > objet implémente une interface (réflexion) ?
> >
> > Merci à tous
> >
> > Johnny
> >
> > (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> > (**) Avez-vous un (bon) lien à ce sujet ?
> >
> > //---------------------------------------
> > //--------------------------------------- Portion de code
> > //---------------------------------------
> >
> > public void Dispose()
> > {
> > this.Dispose( true );
> > GC.SuppressFinalize( this );
> > }
> >
> > public void Dispose( bool disposing )
> > {
> > if( disposing )
> > {
> > // Suppression des objets managés
> > }
> > // Suppression des objets non managés
> > }
> >
> > ~MaClasse()
> > {
> > this.Dispose( false );
> > }
> >
> >
> >
>
>
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
[1] http://www.c-sharpcorner.com/Code/2004/May/PoolingNS.asp
"Pascal Mercier" <pascalme@online.microsoft.com> a écrit dans le message
news:%23np$R$hpEHA.3800@TK2MSFTNGP14.phx.gbl...
> Bonjour,
>
> Voici quelques règles générales à suivre :
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
> les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
> à rien.
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
> 3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
> d'être conservés ouverts (connexions de base de données, fichiers, etc,
> libérer les ressources non managés (références à des objets COM, etc).
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
> 5. En C#, utilisez le mot clé using (...) {..} pour appeler
> les méthodes Dispose(). Ca évite d'oublier.
>
> Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
1.1:
> Using Destructors to Release Resources
> In general, you should NOT be as concerned about memory management as
> would with C++. This is because the .NET Framework garbage collector
> implicitly manages the allocation and release of memory for your
> However, when your application encapsulates UNMANAGED resources such as
> windows, files, and network connections, you should use destructors to
free
> those resources. When the object is eligible for destruction, the
> collector runs the object's Finalize method.
>
> Etes-vous dans le cas d'utilisation de ressources non managés ? Il
> que non.
>
> Tester si une interface est implémentée (C#):
> IMonInterface o = obj as IMonInterface
> if (o!=null)
> {
> // o implémente IMonInterface
> }
>
> Pascal Mercier
> Microsoft France - MCS
>
> "Johnny" <Johnny@antispam.fr> wrote in message
> news:4159c0e9$0$2232$626a14ce@news.free.fr...
> > Bonjour ou bonsoir,
> >
> > Je crée une classe MaClasse implémentant l'interface IDisposable.
> > Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
fin
> de
> > mon message.
> > Je me pose quelques questions au sujet du contenu de la méthode public
> void
> > Dispose( bool disposing )
> >
> > 1) Ma classe contient quelques variables private de type string.
> > qu'il y a un intéret à faire un this.maVariableString = null; ?
> >
> > 2) D'une manière générale, j'envisage de mettre à null tous les
> > managés ou non, et d'appeller au préalable la methode .Dispose() si et
> > seulement si l'objet a été crée par la classe ( et bien entendu si
l'objet
> à
> > "nullifier" propose la méthode Dispose() (*) ).
> >
> > 3) MaClasse travaille avec une base de données et possède une donnée
> private
> > de type IDbConnection. Cet objet de type IDbConnection est un argument
> d'un
> > constructeur; il est aussi accessible en lecture/écriture (get/set)
> une
> > propriété. J'envisage donc, dans mon Dispose, de faire un simple
> > this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
particulier
> > aucun appel à un .Close() ou un .Dispose() car la connexion est
:
> > l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
> objet
> > MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
> autre
> > objet "pointe" déjà une base et est "ouvert". Je passe donc
au
> > constructeur de MaClasse, afin de profiter d'une connexion ouverte et
donc
> > de faire l'économie d'une connexion supplémentaire... Est-ce là une
bonne
> > pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
posts,
> > qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
> mécanisme
> > est efficace et général, je pourrais alors passer plutôt par une
de
> > connexion, et créer une nouvelle connexion réellement propre à
> > puis fermer la conenxion dans le Dispose(), et par exemple ne pas
supposer
> > ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
dans
> > MaClasse...
> >
> > 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier
> un
> > objet implémente une interface (réflexion) ?
> >
> > Merci à tous
> >
> > Johnny
> >
> > (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> > (**) Avez-vous un (bon) lien à ce sujet ?
> >
> > //---------------------------------------
> > //--------------------------------------- Portion de code
> > //---------------------------------------
> >
> > public void Dispose()
> > {
> > this.Dispose( true );
> > GC.SuppressFinalize( this );
> > }
> >
> > public void Dispose( bool disposing )
> > {
> > if( disposing )
> > {
> > // Suppression des objets managés
> > }
> > // Suppression des objets non managés
> > }
> >
> > ~MaClasse()
> > {
> > this.Dispose( false );
> > }
> >
> >
> >
>
>
Vous pourrez trouver une FAQ : "ADO.NET Connection Pooling FAQ" [1]
Si vous lisez cette FAQ, vous vous arreterez peut-être sur la réponse à
cette question :
When is the connection pool destroyed ?
--> When last connection in the pool is closed the pool is
destroyed.
Or vous écrivez :
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
Si la FAQ dit vrai, et que l'application développée travaille seule sur
base locale
et qu'il n'est jamais besoin de plus d'une connexion, alors faut-il en
conclure que
compter sur le pool est une erreur qui peut couter cher coté performances
Dans ce cas précis (et sans doute assez fréquent), n'est-il pas préférable
de
maintenir une connexion ouverte pendant toute la durée d'exécution de
l'application ?
D'une façon plus générale, le pool n'est justifié que s'il est interessant
de travailler en
même temps avec plusieurs connexions, et ce pour une application donnée
un poste donné.
Du temps d'ADO, je n'ai jamais travaillé qu'avec une seule connexion à la
base. Cela sans
rencontrer le moindre problème. Et aujourd'hui comme hier, je ne vois pas
l'interêt d'avoir
plusieurs connexions à ma base (pour une instance de l'application). Si
pouvez éclairer
ma lanterne..?
[1] http://www.c-sharpcorner.com/Code/2004/May/PoolingNS.asp
"Pascal Mercier" a écrit dans le message
news:%23np$R$
> Bonjour,
>
> Voici quelques règles générales à suivre :
> 1. Le code .NET (indépendemment du langage) est managé = fini les "je
libère
> les ressources moi-même". Donc pas de toto=null dans un Dispose, ça ne
sert
> à rien.
> 2. Ne pas utiliser de destructeur, notamment parce que rien ne garanti
> l'exécution exacte de la méthode. Encore une fois le GC (Garbage
Collector)
> s'occupe pour vous de détruire l'objet.
> 3. Implémenter IDispose pour 1) fermer les handles qui n'ont plus besoin
> d'être conservés ouverts (connexions de base de données, fichiers, etc,
> libérer les ressources non managés (références à des objets COM, etc).
> 4. Ouvrir les connexions aux bases de données le plus tard possible et
> refermer le plus tôt dès que possible. En clair, une connexion ne
> pas avoir une durée de vie qui va au delà de la méthode. Le connexion
> est là pour la performance.
> 5. En C#, utilisez le mot clé using (...) {..} pour appeler
> les méthodes Dispose(). Ca évite d'oublier.
>
> Pour info, voici ce qui est dit sur les destructeurs dans le doc du FW
1.1:
> Using Destructors to Release Resources
> In general, you should NOT be as concerned about memory management as
> would with C++. This is because the .NET Framework garbage collector
> implicitly manages the allocation and release of memory for your
> However, when your application encapsulates UNMANAGED resources such as
> windows, files, and network connections, you should use destructors to
free
> those resources. When the object is eligible for destruction, the
> collector runs the object's Finalize method.
>
> Etes-vous dans le cas d'utilisation de ressources non managés ? Il
> que non.
>
> Tester si une interface est implémentée (C#):
> IMonInterface o = obj as IMonInterface
> if (o!=null)
> {
> // o implémente IMonInterface
> }
>
> Pascal Mercier
> Microsoft France - MCS
>
> "Johnny" wrote in message
> news:4159c0e9$0$2232$
> > Bonjour ou bonsoir,
> >
> > Je crée une classe MaClasse implémentant l'interface IDisposable.
> > Vous trouverez (sans entrer dans le détail) l'allure de mon code à la
fin
> de
> > mon message.
> > Je me pose quelques questions au sujet du contenu de la méthode public
> void
> > Dispose( bool disposing )
> >
> > 1) Ma classe contient quelques variables private de type string.
> > qu'il y a un intéret à faire un this.maVariableString = null; ?
> >
> > 2) D'une manière générale, j'envisage de mettre à null tous les
> > managés ou non, et d'appeller au préalable la methode .Dispose() si et
> > seulement si l'objet a été crée par la classe ( et bien entendu si
l'objet
> à
> > "nullifier" propose la méthode Dispose() (*) ).
> >
> > 3) MaClasse travaille avec une base de données et possède une donnée
> private
> > de type IDbConnection. Cet objet de type IDbConnection est un argument
> d'un
> > constructeur; il est aussi accessible en lecture/écriture (get/set)
> une
> > propriété. J'envisage donc, dans mon Dispose, de faire un simple
> > this.MonIdbConnection = null;. Je n'envisage rien d'autre, en
particulier
> > aucun appel à un .Close() ou un .Dispose() car la connexion est
:
> > l'orsque mon objet de type MaClasse est créé, il existe déjà un autre
> objet
> > MaConnexion (de type IDbConenction, ou OleDbConnecttion ou...) et cet
> autre
> > objet "pointe" déjà une base et est "ouvert". Je passe donc
au
> > constructeur de MaClasse, afin de profiter d'une connexion ouverte et
donc
> > de faire l'économie d'une connexion supplémentaire... Est-ce là une
bonne
> > pratique ? Je pose la question car j'ai lu, içi ou là dans quelques
posts,
> > qu'il existerait un mécanisme de "pool de connexion" (**) ? Si ce
> mécanisme
> > est efficace et général, je pourrais alors passer plutôt par une
de
> > connexion, et créer une nouvelle connexion réellement propre à
> > puis fermer la conenxion dans le Dispose(), et par exemple ne pas
supposer
> > ou vérifer que MaConnexion est ou non ouverte lorsque j'en ai besoin
dans
> > MaClasse...
> >
> > 4) Accessoirement, je suppose qu'il y a un moyen (simple) de vérifier
> un
> > objet implémente une interface (réflexion) ?
> >
> > Merci à tous
> >
> > Johnny
> >
> > (*) Même chose pour le "Close()" si "Open()" réalisé dans la classe
> > (**) Avez-vous un (bon) lien à ce sujet ?
> >
> > //---------------------------------------
> > //--------------------------------------- Portion de code
> > //---------------------------------------
> >
> > public void Dispose()
> > {
> > this.Dispose( true );
> > GC.SuppressFinalize( this );
> > }
> >
> > public void Dispose( bool disposing )
> > {
> > if( disposing )
> > {
> > // Suppression des objets managés
> > }
> > // Suppression des objets non managés
> > }
> >
> > ~MaClasse()
> > {
> > this.Dispose( false );
> > }
> >
> >
> >
>
>