Discussion :

[WriteLN]

Bonjour à tous,

Je développe une classe que mon application va instancier assez souvent.
Dans le new de cette classe, je passe en paramètre une référence à l'objet connection SQL.
L'opération du new est de vérifier que l'ID fourni existe bien au niveau base de données et de charger les informations attachées.
Dans le cas ou l'ID n'existe pas, le new lance une exception.
Je récupère bien mon exception au niveau de mon application.

Ma question est de savoir comment demander à l'objet de s'auto-détruire si l'ID n'est pas valable.
En effet, lancer une exception ne détruit pas l'objet.

Est-ce automatiquement la responsabilité de mon application de détruire l'objet si elle reçoit l'exceptionou existe-t-il une commande permettant, dans le new, de détruire l'objet lui-même.
Je suis d'accord que c'est un peu comme de couper la branche sur laquelle on est assis mais dans mon cas, çà m'aiderait.

Merci d'avance pour toute info.

PS: Pour chaque objet que je crée, je transmet une référence à l'objet de connection SQL. Est-ce la meilleure approche ou serait-il préférable que chaque objet se reconnecte lui-même à ma DB? Sachant que je vais en instancier pas mal.

[Piotrek]

Salut

Ta classe ne fait que verifier l'existance d'un ID? dans ce cas je pencherai juste pour une fonction ailleurs, plus de question d'instanciation donc

Pour ce qui est de la connection, cela depend. En .Net il est generalement deconseille de reutiliser une connection ouverte. Le systeme du pooling de .Net se charge de mettre en cache les connections a la base de donnees. Il est donc conseille d'ouvrir la connection le plus tard possible et de la refermer le plus tot possible.

Autre remarque au cas ou:
Il ne faut utiliser les exceptions que lorsqu'il sagit d'une anomalie de fonctionnement de l'application (dans ton cas la logique serait: il doit absolument toujours y avoir un ID) et non pas pour effectuer un simple test.

[SaumonAgile]

Ta classe ne fait que verifier l'existance d'un ID? dans ce cas je pencherai juste pour une fonction ailleurs, plus de question d'instanciation donc

+1
Pourquoi ne pas faire une méthode statique ?

Pour ce qui est de la connection, cela depend. En .Net il est generalement deconseille de reutiliser une connection ouverte. Le systeme du pooling de .Net se charge de mettre en cache les connections a la base de donnees. Il est donc conseille d'ouvrir la connection le plus tard possible et de la refermer le plus tot possible.

Ce qui, pour clarifier les choses, signifie que chaque objet gère sa propre connexion à la base. En interne le framework fait sa cuisine, il n'ouvre et ne ferme pas forcément les connexions lors de l'appel de Open et Close sur une IDbConnection. Mais pour toi cela est transparent. Donc au final, utilise une nouvelle connexion pour chaque objet et laisse le framework faire le boulot.

Autre remarque au cas ou:
Il ne faut utiliser les exceptions que lorsqu'il sagit d'une anomalie de fonctionnement de l'application (dans ton cas la logique serait: il doit absolument toujours y avoir un ID) et non pas pour effectuer un simple test.

+1 aussi.

[WriteLN]

Citation:
Envoyé par Piotrek
Ta classe ne fait que verifier l'existance d'un ID? dans ce cas je pencherai juste pour une fonction ailleurs, plus de question d'instanciation donc

+1
Pourquoi ne pas faire une méthode statique ?

Au new, ma classe vérifie l'ID mais elle ne fait pas que çà. Elle va aussi disposer de méthodes de calcul, ...
Donc la classe reste dans mon cas la solution.

Citation:
Envoyé par Piotrek
Autre remarque au cas ou:
Il ne faut utiliser les exceptions que lorsqu'il sagit d'une anomalie de fonctionnement de l'application (dans ton cas la logique serait: il doit absolument toujours y avoir un ID) et non pas pour effectuer un simple test.

Lorsque j'instancie ma classe, je lui passe l'ID de l'élément.
- Première vérification, l'ID existe? Non, alors j'envoie une exception et exit le new (l'objet n'est donc pas créé)
- Deuxième vérification, structure de l'ID (8 caractères maxi)
Non, alors j'envoie une exception et exit le new (l'objet n'est donc pas créé)
- Ultime vérification, l'ID existe dans la base de données?
Non, alors j'envoie une exception et exit le new (l'objet n'est donc pas créé)

J'utilise les exception pour transmettre la nature de l'erreur à la form qui instancie la objet.
Y a-t-il une autre manière de faire? Sachant que je n'ai pas développé de classe spécifique pour mes exceptions(pour le moment)

Citation:
Envoyé par Piotrek
Pour ce qui est de la connection, cela depend. En .Net il est generalement deconseille de reutiliser une connection ouverte. Le systeme du pooling de .Net se charge de mettre en cache les connections a la base de donnees. Il est donc conseille d'ouvrir la connection le plus tard possible et de la refermer le plus tot possible.

Actuellement, j'ouvre la connexion au démarrage de l'appli et la passe en référence à chaque classe qui en a besoin.

Tu penses que chaque objet devrait être responsable pour recréer une connection SQL? Si j'ai 2000 dossiers à instancier, j'aurai 2000 connection?
Ces un débat que je tourne et retourne dans ma tête depuis quelques jours et j'aimerais connaître votre manière de faire. Un exemple?

Merci pour toutes vos piste que je vais essayer de mettre en place.

[SaumonAgile]

Tu penses que chaque objet devrait être responsable pour recréer une connection SQL? Si j'ai 2000 dossiers à instancier, j'aurai 2000 connection?
Ces un débat que je tourne et retourne dans ma tête depuis quelques jours et j'aimerais connaître votre manière de faire. Un exemple?

Si tu relis ma réponse précédente, tu auras la réponse à ta question. Mais je vais quand même le redire. Le framework gère les connexions en interne, ce n'est pas parce que tu crées 2000 objets DbConnection que tu vas ouvrir 2000 connexions à la base. Le framework gère un pool de connexions.

[Piotrek]

En fait l'objet ne s'auto detruit pas.

C'est a l'objet qui a cree ton verificateur qu'incombe la responsabilite de le detruire. C'est pour cela que Finally existe. L'autodestruction n'existe pas

Y a-t-il une autre manière de faire? Sachant que je n'ai pas développé de classe spécifique pour mes exceptions(pour le moment)

A part si tu fais une application pour verifier la validite de donnees deja presentes en base (ce que tu fais apparement), dans les autres cas les d'infos concernant la validite des donnees en base peuvent etre gerees differment:
- Si l'id unique existe en base et que tu tente d'inserer une donnees: tu ne fais pas le test de savoir s'il existe mais tu intercepte l'exception specifique d'ado.net qui te signale ce probleme apres avoir tente d'insere la donnee
- Si une donnee doit comporter 8 caracteres, tu fais ton possible pour qu'en amont dans l'IMH (textbox de 8 char max) ou au niveau de l'objet, tout est fait pour que cela soit 8 caracteres. Si tu mets ces garde fous

Donc comme apparement tu fais des verifications uniquement, je pense que tu fais bien.

Actuellement, j'ouvre la connexion au démarrage de l'appli et la passe en référence à chaque classe qui en a besoin.

Ca, ca marchait tres bien sous VB6. Mais ADO.Net a change la donne. Il existe un systeme de cache qui garde les connections a la base de donnees. Le but du jeux est d'avoir une seule connection active, dans ton code tu peux ouvrir et refermer une SqlConnection de partout, en fait ca sera la meme (a la condition que la connection string soit identique et qu'elle ait le temps de se referemer). A mon avis le code est plus sur et une partie de la mechanique d'une SqlConnection ne mobilise pas des ressources en permanence.

Tu penses que chaque objet devrait être responsable pour recréer une connection SQL? Si j'ai 2000 dossiers à instancier, j'aurai 2000 connection?
Ces un débat que je tourne et retourne dans ma tête depuis quelques jours et j'aimerais connaître votre manière de faire.

Tes 2000 dossiers tu peux les charger dans une collection en une seule requete/connection, il faudrait en dire plus sur ce que tu fais

[WriteLN]

Donc si mon objet, au NEW, renvoie une exception, l'objet responsable de la création fait le catch et détruit celui-ci.

Pour la connection à SQL, je vais devoir repenser mon application alors.
Malgré qu'elle fonctionne très bien sur cet aspect la mais je préfère être sûr.

Enfin, pour le concept, c'est une application qui, entre autres..., ouvre un fichier XML, lis les ID des items les uns après les autres, instancie pour chaque items la classe d'affichage graphique de 'objet' qui elle instancie la classe métier pour les données.
Ces objets sont affichés à l'écran et l'utilisateur peut interagir avec eux (doubleclick, click, drag, ...)

Merci encore pour tout. on peut dire que c'est résolu. J'ai saisi l'idée
La prochaine fois, je ferai des études de masseur C moins compliqué