Discussion :

[looping]

bonjour,

d'une manière générale que ce soit avec le BDE ou interbase/firebird:

il faut mieux utiliser un datamodule ou pas pour poser les composant de connexion au base ?



merci

[dd_garion]

Il est toujour préférable de séparer l'interface - la couche métier - la couche acces DB.

Tu peux donc rassembler dans un ou plusieurs datamodules tes composants et fonction qui accès à la DB.

C'est une façon de faire "élégante" (pour moi)

[ShaiLeTroll]

En fait le DataModule c'est utile mais cela peut devenir trop énorme lorsque tu mets autant de TTable que tu as de table dans la base ... ayant vu des DataModule avec plus de 300 composants c'est horrible ...

Pour séparer le métier de l'interface, il vaut mieux faire des objets métiers qui regroupent la données (sous forme de propriété pour les plus utilisées, sous forme d'un FieldBtName comme le DataSet pour les autres), ainsi que les traitements (Nouveau, Modifier, Supprimer, Lier Table A avec Table B ...)

Ensuite, certains diront que tout le métier peut être mis dans des procédures stockées, mais là ... c'est un autre débat ...

De plus, tu vas souvent devoir lancer des SQL, donc
soit tu as des objets globaux que tu changes à chaque fois, vive le sac de noeud
soit tu as un objet par query, ouch, ça risque d'être lourd ... mais cela peut t'amener à faire un objet dans le genre de celui ci au lieu d'un DataModule ...
soit tu fais de l'allocation dynamique, et tu es rigoureux pour tes libérations, voir ce sujet

Pour InterBase, si tu utilise les composants IB comme le IBQuery, il faut savoir que le prepare n'est pas implicite contrairement à la plupart des composants DB ... donc il faut créer autant de Query que de SQL, les préparer (à l'avance, choisir le moment opportun comme le chargement de l'application pour les plus utiliser, à la première utilisation pour les autes), ... n'ayant jamais poussé avec les composants IB, j'ignore si l'on prépare une requête sur le serveur, si lorsque l'on détruit l'objet est-ce que la requête est libérée aussi ou si c'est fait à la fermeture de la connexion ... au final, les composants ADO sont plus efficace ...

je m'écarte ...

[Franck SORIANO]

Personnellement, chaque fois que je peux, je proscris les TTable et TStoredProcedure.

Je fais tout par requêtes SQL. Donc le problème est réglé, je n'ai pas besoin de poser les composants sur quoi que ce soit.

Je gère un composant de type Database en singleton dans l'application. Sur ce composant, je veille à ce qu'il possède deux méthodes :
- ExecSQL : Une méthode a laquelle je fournis le code SQL d'une requête (une chaîne de caractères), avec éventuellement une liste de paramètres (un TParams). Cette méthode exécute la requête fournie en paramètre et ne retourne aucun résultat.
- OpenSQL : Une fonction qui attends les mêmes paramètres que ExecSQL sauf que celle-ci est destinée à exécuter une requête qui retourne un résultat. En retour la fonction renvoie un TDataSet créer dynamiquement que je peux ensuite lire ou connecter à une grille.
Comme l'a indiqué ShaiLeTroll, il faut juste faire attention à bien détruire le DataSet à la fin.

Avec ça, tu fais tout. Les query, pour appeler une SP tu fais une requête SQL qui appelle la SP...

Tu implémentes le composant database en fonction de l'API que tu veux utiliser. Pour ADO, Tu as la méthode Execute. Pour dbx, le composant TSQLConnection fonctionne déjà comme ça.
En plus, le reste de ton code est indépendant de l'API utilisée et tu peux en changer en un claquement de doigt (dans mon dernier projet, je crois que j'ai bien dû toutes les essayer (ADO, dbx, NCOCI, OLEDB, OCI...)).