Fonction qui regroupe les commandes sql

Salut,

Je vais sur un nouveau projet !

Et la première chose que j'aimerai faire c'est regrouper dans un module une fonction SQL qui s'occupe des " insert, update, delete, et select " et quand j'ai en ai besoin je fais appel à elle et j'envoie des paramètres .

J'aimerai savoir comment organiser la fonction qui me permettrait de faire ça?

Est ce que j'envoie juste en paramètre une chaine de caractère qui contient toute la requête ou puis-je faire plusieurs paramètre :

Le 1er paramètre, reconnaître le type de commande(insert,delete,update)
Le 2eme paramètre, Le nom de la table
Le 3eme paramètre, les textbox qui vont remplir les champs
Le 4eme paramètre, une clause where
?

J'aimerai que ce module soit le plus standart possible et que je puisse l'organiser dans d'autres projets.

Merci

ce qui se fait en général c'est une classe (pas un module) pour encapsuler tout ca, avec une fonction d'exécution de requete simple et une fonction d'exécution de requete select (qui retourne le datareader ou les données)

morceaux d'exemple pour sql server :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

public class DataClass   private shared _connectstring = "server=..."   public sub ExecuteNonQuery(requete as string, paramarray params() as system.Data.sqlclient.sqlparameter) try using c as new sqlclient.sqlconnexion c.connectstring = _connectstring c.open dim cmd as new sqlcommand ' si le command est disposable, utiliser un using comme pour le connection cmd.connection = c cmd.commandtext = requete for each p as sqlparameter in params cmd.parameters.Add(p) next cmd.executenonquery end using catch ex as exception ' la connection n'a pas pu s'établir ou la requete à planté ou timeout ou autre end try end sub   end class

---

pour access c'est l'espace de nom system.Data.oledb et donc le system.Data.oledb.oledbparameter par exemple

paramarray sert à dire qu'il va y avoir entre 0 et n parametres fournis (donc soit juste donner la requete, soit la possibilité de mettre autant de variable qu'on veut derrière avec des ","
un dbparameter sert à sécuriser les requetes paramétrées, et d'éviter les bugs ; ca simplifie aussi la lecture de la requete !
concaténer la requete avec des textbox est plus que déconseillé

exemple d'utilisation :

Code:

---

1 2 3 4

dim d as new dataclass dim paramNom as new data.sqlclient.sqlparameter("@pnom",me.Textbox1.text) dim requete as string = "insert into matable (nom) values (@pnom)" d.executenonquery(requete,paramNom)

---

si tu ne veux pas faire de multithreading, tu peux mettre tes membres en shared, ou utiliser un module

pour le executenonquery, tu peux faire soit une fonction qui retourne true ou false selon la résultat de l'exécution
ou encore retourner l'erreur à l'appelant

pour le executeselect tu peux soit retourner le datareader, et l'appelant boucle dessus, ou encore retourner un datatable, comme ca l'appelant n'a que le code de son traitement !

ce code peut etre adapté et complété selon tes besoins, tu peux par exemple sur la classe exposer une propriété pour définir le commandtimeout (avec une valeur par défaut) des fois que tu as besoin de l'agrandir dans certains cas


pour les exception, il convient de les logger afin de pouvoir débugger ton programme facilement (ex.message et ex.stacktrace au moins)

Bonjour,

Citation:

---

c'est regrouper dans un module une fonction SQL qui s'occupe des " insert, update, delete, et select "

---

Il serait plus judicieux de créer une interface SQL. Et ensuite implémenter cette interface dans chaque objet.
[Edit]
Le message précédent et le mien ce sont croisés.
[/Edit]
A+

Ok merci ça correspond totalement à mes besoins, j'en avais pas demandé autant ^^ mais merci :D :ccool:

Et ensuite pour chaque projet ,j'aurai juste à importer cette classe ou je peux en faire une reference?

@Pol63

Ton code rien à redire, mais au niveau modélisation, ne crois tu pas que pouvoir ce connecter à une source de donnée en fonction de l'objet permet une plus grande souplesse qu'avec une classe ? D'où l'interface.

A+

Citation:

---

Envoyé par champomy62

Et ensuite pour chaque projet ,j'aurai juste à importer cette classe ou je peux en faire une reference?

---

tu peux mettre ca dans une dll avec plein de choses d'autres qui sont génériques à tous tes projets

dans ce cas par contre il ne faut pas mettre la chaine de connexion en dur, car elle dépendra du projet, il faut alors pouvoir la donner à l'objet
tu peux par exemple faire un propriété shared ou tu injecteras la chaine de connexion "par défaut" au démarrage de l'appli, et une surcharge du new qui en demande une, des fois que tu ais besoin dans un même programme de te connecter à plusieurs bases

Citation:

---

Envoyé par Geo2A

@Pol63

Ton code rien à redire, mais au niveau modélisation, ne crois tu pas que pouvoir ce connecter à une source de donnée en fonction de l'objet permet une plus grande souplesse qu'avec une classe ? D'où l'interface.

A+

---

oui, ca dépend de ce qu'on veut faire, si on pouvoir gérer plusieurs types de base de données ou pouvoir migrer la base de son appli il faut faire une classe plus générique (ou une interface) et un factory qui te retourne l'instance du type de base de données que tu souhaites
mais quand on y réfléchis la syntaxe sql d'une base à une autre n'est pas forcément la même
ou alors après on passe au niveau au dessus et on fait un classe qui ne demande pas une requete mais qui exprime ce qu'elle veut et la classe génère la requête
m'enfin au moins on a posé quelques bases d'encapsulation d'accès aux données, à adapter selon les besoins

Je croyais que le using été utilisé seulement dans c# !?

using de c# en début de fichier équivaut à imports en vb.net

le bloc using dans du code sert à disposer les variables disposables

merci de ta reponse

Salut,

je me posais juste une question par rapport à la fermeture de la connexion...

Dès que

Code:

---

cmd.executenonquery

---

est executé, la connexion est fermée ?

non

connection.close ou meme connection.dispose ferme la connexion

car après un executenonquery, tu peux recharger le commandtext avec une autre requete et refaire un executenonquery

:ccool:

pour info, certains ne le savent pas, dans le commandtext on peut mettre plusieurs requetes tel une procédure stockée

exemple pour avoir une clé auto incrément après un insert :

Code:

---

cmd.commandtext = "insert into table (ch) values (@v)" & vbcrlf & "select scope_identity()"

---