Discussion :

[leSeb]

Bonjour,

Je sais que le sujet a été abordé plusieurs fois sur ce forum, mais j'ai toujours du mal avec ca ...

Comment peut-on savoir si une ressource est managée ou pas ?

Par exemple, est ce que OdbcConnection est une ressource managée ?

Je travaille sur le destructeur de ma classe et j'ai donc implémenté l'interface IDisposable. Mais voilà ce qu'ils mettent dans l'aide :

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
Public Class Base
    Implements IDisposable
    ' Implement IDisposable.
    Public Overloads Sub Dispose() Implements IDisposable.Dispose
        Dispose(True)
        GC.SuppressFinalize(Me)
   End Sub 
 
    Protected Overridable Overloads Sub Dispose(ByVal disposing As Boolean)
        If disposing Then
            ' Free other state (managed objects).
        End If
        ' Free your own state (unmanaged objects).
        ' Set large fields to null.
   End Sub 
 
    Protected Overrides Sub Finalize()
        ' Simply call Dispose(False).
        Dispose(False)
   End Sub 
End Class

Supposons que ma classe possède deux attributs, un de type ODBCConnection et l'autre de type DataSet.

Où dois-je mettre l'appel de la méthode Dispose() de chacun des éléments ? Dans unmanaged ou managed object ?


Merci pour votre aide car, pour moi, c'est vraiment pas clair.

[neguib]

Supposons que ma classe possède deux attributs, un de type ODBCConnection et l'autre de type DataSet...

Dans ce cas de figure ce sont des objets qui ciblent le CLR donc managés. Je suppose qu'il faudrait par exemple des objets C++ pour les traiter dans la partie non managée.

[leSeb]

Dans ce cas de figure ce sont des objets qui ciblent le CLR donc managés.

Mais qu'est ce que le CLR, et comment peut-on connaitre les objets qui ciblent le CLR ?

[Piotrek]

Imagine toi DotNet comme une application dans windows, elle communique avec tout ce qu'il y a autour d'elle: reseau, harware, windows etc

Donc suffit de penser:
- Une String est elle une ressource managée? oui, son existance est limitée dans DotNet
- Un controle est il une ressource managée? non, car DotNet ne fait que représenter en son environnement des composants qui existent en dehors: c'est windows qui effectivement crée le controle
- En regle générale: Tout ce qui est a l'exterieur de dotnet peut etre appele, mais doit etre explicitement detruit car sinon ce que tu as pu appeler peut rester actif

En cas de doute:
- S'il existe une methode dispose c'est qu'il y a de tres fortes chances que le type qui la possède, gère a un moment ou à un autre quelque chose de non managé, et donc qu'il faut l'appeler
- Certains types possèdent dispose, alors qu'apparement il n'y a aucune raison qu'il gerent quoique ce soit de managé: il faut vérifier avec Reflactor, pour voir que'est ce que ca pourrait bien être. Parfois le dispose d'un objet que tu gere va appeler le dispose d'un autre objet que tu gere aussi, faire un dispose explicite du deuxieme objet pourrait parraitre inutile, mais en aucun cas c'est dangereux d'appeler dispose deux fois sur un meme objet

Bref systematiquement appeler dispose, systematiquement implementer IDisposable si le type que tu cree et gere a quelque chose de disposable

EDIT: en relisant ta question, un autre probleme d'ordre architectural existe aussi: qui cree ton objet? qui le detruit? T'est pas forcement oblige d'implementer IDisposable: ton type est il par essence non managé?

Pour repondre a ca:
La duree vie de l'objet est elle la meme que celle de la ressource managee qu'il contient?
Oui (Style, ton objet englobe et propose une Connection): Il faut implementer IDisposable
Non (il se connecte, remplit et renvoie un dataset, referme la connection et attend l'appel suivant): Pas d'IDisposable, t'apelles le Dispose de la connection juste avant de sortir de la fonction qui renvoie le dataset

[leSeb]

Merci pour ta réponse très précise Piotrek ...

Dernière question pour être sur de bien comprendre. En faite, les ressources managées sont :

- Une classe dériviée de la classe Component
- Une classe qui intègre un attribut d'une classe dérivée de la classe Component ( dans le cas ou la durée de vie de l'attribut est la même que la durée de vie de l'instance comme tu l'as si bien expliqué).

[Piotrek]

N'importe quoi qui fait appel a une api non dotnet directement ou indirectement est non manage, il n'y a donc pas un type precis dans le framework qui decrit l'objet manage, c'est un etat de fait en soi

Tout ce qui se trouve dans les "Component" "ComponentModel" c'est un peu a part:

Quand t'utilise l'IDE lors de la conception de ton projet, les controles ou une connection a une BD par exemple se chargent aussi, bien que tu sois pas en execution, ce sont des ressources non managees utilisees. Component c'est leur representation dans une structure dans l'IDE (IComponent, ISite etc...): tu fermes ton projet, la connection a la base qui te permet de voir les tables lorsque tu construit visuellement ton dataset doit etre disposee aussi
Donc je vois Component quelque part, je me dis: ah c'est dans l'IDE et le Dispose, c'est l'ide qui l'apelle (D'autres classe du NameSpace ComponentModel peuvent etre utilisees a d'autres fins mais c'est une autre histoire)

Je sais pas si j'ai ete clair

[leSeb]

Excuse-moi si je suis un peu perdu ....

Si je résume ce que j'ai compris (du moins je pense avoir compris !!!)
- mon objet n'est pas managé si utilise une ressource qui est externe au framework (fichier, API, ...) ou s'il contient un attribut non managé.
- mon objet est managé dans les autres cas.

Dans le premier cas, il est impératif de détruire l'objet explicitement car le GC ne le fera pas nécessairement.
Dans le deuxième cas, ce n'est pas obligatoire (bien entendu, c'est fortement recommendé) car le GC le fera de toute façon (en différé ...)

Biensur cette explication me gène puisque que dans ce cas, je considère que ODBCConnection est non managée, File est non managé, ...

Par contre, je confirme que String est managé.

Merci pour ta patience

[Piotrek]

Biensur cette explication me gène puisque que dans ce cas, je considère que ODBCConnection est non managée, File est non managé

Pourquoi ca te generait?

[leSeb]

leSeb a écrit:
Supposons que ma classe possède deux attributs, un de type ODBCConnection et l'autre de type DataSet...

Dans ce cas de figure ce sont des objets qui ciblent le CLR donc managés

Parce que c'est contradicatoire avec la réponse de neguib

[Piotrek]

Bah, a un moment ou a un autre il y aura bien une intervention du C++ lors de la connection

[leSeb]

Que veux-tu dire par là ? .......

[Piotrek]

Je vais preciser:

ODBCConnection gere des ressources non managees, lui meme ce n'est pas une ressource non managee en soi

[leSeb]

- mon objet n'est pas managé si utilise une ressource qui est externe au framework (fichier, API, ...) ou s'il contient un attribut non managé.
- mon objet est managé dans les autres cas.

Devrais-je corriger de cette manière alors ?
- mon objet n'est pas managé si utilise une ressource qui est externe au framework (fichier, API, ...)
- mon objet est managé dans les autres cas.

[Piotrek]

Tous les types du framework sont par nature manages, en revache il y a:

- ceux qui gerent des ressources externes/non managees (fichier API...) qui devraient posseder un Dispose
- ceux qui n'en gerent pas

[leSeb]

Merci beaucoup pour tes précisions ....