Et ton intention était plus qu'honorable !
C'est pourquoi je me suis permis de prendre le temps de te répondre en essayant de justifier mes critiques...
Je dis bien "justifier" car je ne suis pas le dieu de .Net [et je le connais pas non plus] et j'ai peut-être tort dans ce que je dis. C'est pourquoi j'essaie toujours de justifier mes dires pour essayer de donner une logique à ceux-ci.
Maintenant, il ne tient plus qu'à toi de savoir accepter ces dernières (trier ce qui t'intéresse de ce qui ne t'intéresse pas) pour avancer et améliorer tes compétences en .Net.

Je te rassure de suite: on est tous dans ton cas et ce, tous les jours qu'il nous est permis de coder... et c'est pas facile tous les jours... :D

Bonjour,

Il est inutile de prendre la mouche sur un commentaire. Après tout, tu as posté ce code pour avoir l'avis et commentaires de tout un chacun.


Je me permettrai donc d'ajouter le mien:
1) Convention de nommage pas très rigoureux: mélange français-anglais, nom de classe et méthodes non explicites...

2) Problème d'ouverture et fermeture de connexion: l'ouverture est faite dans le constructeur
et la fermeture est inexistante...
Comment ferais-je si la connexion se perd au milieu de mon programme ??? (toutes les méthodes ne fonctionnent plus).
Comment ferais-je pour gérer les transactions ???

3) Le remplacement des exceptions par un code retour entraine un grosse perte d'information dans le code appelant. De plus, en cas d'exception, un MessageBox.Show(...) est appelé => pas très best-practice tout ça. En effet, si je veux utiliser ta brique dans un projet Asp.Net, que se passe-t-il en cas d'exception ???

4) Retour d'exécution de commande dans une ArrayList[ArrayList[object]] pas très best-practice non plus (et je passerai la méthode de lecture qui est discutable aussi) => préférer l'utilisation d'un DataSet plus adaptée au fonctionnement.


Et plutôt que "d'adapter à mes besoins" (comme tu le dis si bien), je préférerai largement l'utilisation d'une librairie plus qu'approuvé par la communauté .Net: Enterprise Library.
Url: http://msdn.microsoft.com/en-us/library/ff648951.aspx
En l'occurence, la partie "Data Access Application Block": http://msdn.microsoft.com/en-us/magazine/cc163766.aspx
C'est en open source, tu auras donc le plaisir de pouvoir voir tout le code d'accès aux base de données.

Bref, tu comprendras que je suis plutôt d'accord avec le commentaire de Sebmafate.


Ne vois pas là une intention de ma part de te froisser, uniquement celle de donner mon avis pour faire vivre l'échange communautaire créé par codes-sources et nous faire tous avancer...
Car savoir accepter les critiques et se remettre en cause, c'est la raison d'être d'un développeur...

Bonjour,

En plus des commentaires de merlin2000 et shenron666, j'ajouterai les remarques suivantes:
1. Pourquoi supprimer les fichiers du répertoire avant de supprimer le répertoire alors que la méthode Directory.Delete(string, bool) peut s'en charger: http://msdn.microsoft.com/fr-fr/library/fxeahc5f%28v=VS.80%29.aspx .

2. L'utilisation de la ligne:
if (e.ToString() == "System.UnauthorizedAccessException")
est plus que déconseillée. On pourrait même dire que c'est un "bad-practice".
Il faut préférer le code suivant:
catch(UnauthorizedAccessException ex)
{
  // Ici pour unauthorized...
}
catch (Exception ex)
{
  // Ici pour les autres types d'exception...
}

3. Ne pas nommer une fonction qui ne fait pas ce qu'elle dit. ie:
- "delete_repertoire" ne supprime pas le répertoire car elle le re-créé à la fin...
- "check_directory" créé le répertoire alors que ce n'est pas la traduction de check...
- etc...

4. Le mélange de français/anglais n'est pas des plus séduisant. Choisis une ligne de conduite et tiens là.

5. Pas mal de choses seraient aussi à revoir au niveau de la gestion des exceptions, de la sortie console des infos, etc...

Tout ceci empêche complétement la ré-utilisabilité de ce code.

Salut à tous,

En faisant abstraction du fait que ce code soit ou non utile pour les débutants (point sur lequel je rejoins plus TMCUH), je trouve personnellement que ce code est un bon challenge personnel (ce qu'a du se dire LOUDADYASSINE).
Cela me rappelle l'époque (que je me sens vieux en disant ça ;p ) où certaines personnes étaient tellement en avance pour les projets informatiques de fin d'année qu'ils se lançaient des challenges: "à qui fera le jeu en moins de [XXX]Ko) ?". Certes, les "best practices" n'étaient peut être pas au rendez-vous mais cela permettait de tenir en haleine les petits geeks comme nous le sommes un peu tous aujourd'hui.

C'est pourquoi, je pense qu'il ne s'agit certainement pas d'un code de conduite à suivre par les débutants mais plutôt d'un petit challenge pour les gens ayant déjà fait le tour de pas mal de points et lassés de toujours corriger les mêmes bugs au boulot...

Bonne journée à tous,

@loudadyassine: peut-être aurais-tu pu te présenter à incroyable talent avec ce snake en moins de 100 lignes de code (mais le jugement de Mr Rozon aurait certainement été le même que TMCUH ;p )

@LASSAAD83:

En effet, il est vrai que l'UpdatePanel comble le même besoin. Plus facile à coder, peut-être; mais permet-il d'augmenter la performance de la page ???
Je n'en suis pas si sûr...

Un simple test de cette source et d'une source équivalente avec l'UpdatePanel te permettra de remarquer que le flux réseau (avec firebug sous firefox) de rafraichissement de ta page est largement plus conséquent avec un UpdatePanel. En effet, ce dernier emporte énormément d'information avec lui qui ne sont pas toutes pertinentes.
Et je dirai même plus, si tu fais un test avec un simple postback (sans UpdatePanel) de ta page te montrera que tu n'es pas loin du flux de l'UpdatePanel.
Voici quelques liens:
- http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
- http://msdn.microsoft.com/fr-fr/magazine/cc163413.aspx

C'est pourquoi je pense que la solution proposée par Driver fait partie des bonnes pratiques que j'essaie toujours de mettre en place dans mes projets.

Donc, OUI, je vote pour cette solution plutôt que pour un UpdatePanel (qui n'a pas de raison d'être pour ma part)...

Si je met pas de notes... (dsl)

Source intéressante. (manque un p'tit peu de commentaire qd même)

Il est vrai que ça devient vite rébarbatif de créer N événement avec autant de fonctions "delegates" qui vont bien.
Cependant, je reste encore persuader que ce travail est nécessaire, qui plus est si les classes implémentées sont emmenées à devenir une bibliothèque partagée sur Internet ou fournie à d'autres projets.

Merci !
Source très intéressante d'utilisation de Web Services en javascript. A user et abuser dans les développements asp.net ^^

Pour information, un tel type de besoin peut aussi conclure à une implémentation via la mise en place d'un service "AJAX-enabled WCF Services" (Framework 3.5). La technique est quasi identique.
Un très bon tutorial: http://www.pluralsight.com/community/blogs/fritz/archive/2008/01/31/50121.aspx

Sur le tard, mais comme d'habitude, j'en apprend tous les jours sur Codes-Sources.
Je connaissais pas le BackGroundWorker (et j'ai même découvert le ErrorProvider ^^).
Dommage, on reste un peu trop dans ses idées et on veut jamais changer sa manière de coder alors que des trucs tout simples comme ceux-là peuvent vraiment apporter un +.

Précis et Concis !
Source très bien expliqué
Merci !


Billou_13

Juste une petite question ^^
Pour ton fichier "Block.png", pourquoi ne l'as tu pas mis à la racine de ton projet avec comme la propriété "Copy To Output Directory" en "Copy Always" ou "Copy if newer" ?
Ca aurait été plus simple que de devoir le mettre dans le répertoire Debug qui sera effacé en cas de Clean ou Rebuild.


Billou_13

PS: je regarderai ton code dès que j'aurai résolu mon bug ^^