Discussion :

[eponette]

Juste une petite question sur votre expérience. Perso, je ne fais qu'un DataModule avec tout dedans. Mais est-ce la meilleure manière? Qu'en pensez-vous?

[qi130]

C'est aussi comme ça que je procède.

[Rayek]

Juste une petite question sur votre expérience. Perso, je ne fais qu'un DataModule avec tout dedans. Mais est-ce la meilleure manière? Qu'en pensez-vous?

Ca depend du type d'applications.

Si l'application a peu de form/frame 1 seul datamodule c'est suffisant.
Des que l'application commence à en avoir beaucoup (form/frame) pour eviter des milliers de lignes de code dans le datamodule, il est préférable d'en avoir plusieurs.

Pour ma part j'ai créé une application avec un Datamodule général (Connexion + fonctions/procédures communes), et des datamodules enfant par frame lié au général avec leurs tables/query et toutes leurs fonctions/procédures.

Mais bon, ce n'est qu'un avis perso.

[e-ric]

Bonjour

Je vais soulever plusieurs points (liste sans doute non exhaustive) qui vont à l'encontre de la définition d'un seul DataModule.

Cohérence de la structure du projet
Je pense que ce n'est pas une bonne pratique si ton application est de taille importante ou peut le devenir. En effet si tu décris toutes les règles de gestion des objets du Datamodule dans celui-ci, cela va augmenter rapidement sa taille et rendre difficile sa compréhension et donc sa maintenance.
Le partage du DataModule entre plusieurs fiches induit un couplage très fort et peut amener à faire des hypothèses sur un objet A utilisé par une fiche B qui s'avèront inadaptées pour une fiche C qui utilise aussi A. Cela peut nuire à l'évolutivité de ton projet.


Cas du partage des sources
Autre aspect du problème, dans une application mettant en jeu une équipe de développeurs, le fait de partager ton DataModule entre plusieurs fiches peut devenir un goulot d'étranglement car plusieurs développeurs peuvent être amenés à le modifier simultanément. Si le source est verrouillé par un développeur, un autre développeur devra attendre son tour, cela peut être générateur de dérive en temps et aller contre la philosophie RAD. Cette remarque prévaut aussi pour les unités "globales" trop fréquentes dans les projets que j'ai pu avoir en maintenance à mon sens.

Temps de chargement
Si tu places tous tes composants non-visuels dans un seul DataModule, ceux-ci seront créés systématiquement au démarrage de ton application dès lors que ton DataModule est chargé, d'où un temps de chargement élévé et une consommation importante de mémoire. La question est : est-ce que tous ces composants sont nécessaires à chaque exécution ?

Ma réponse est qu'il vaut mieux travailler avec une granularité fine et donc fragmenter intelligement le DataModule principal et charger les DataModule résultants selon les besoins.

Mais il n'y a pas de règle absolue, le dogmatisme n'est pas une bonne pratique. En outre, si tu reprends un projet existant avec un DataModule unique, il faudra certainement composer avec, le refactoring (réorganisation de la structure du projet) n'est pas toujours possible.

Voilà j'ai abordé les aspects du problème qui me sont venus à l'esprit, il serait très intéressant d'avoir d'autres avis sur le sujet.

Cordialement

e-ric

[Bloon]

Sur les gros projets, je crée un DataModule qui représente la base de données puis un DataModule par table. Ils sont créés / détruits dynamiquement au fur et à mesure des besoins.

Bloon

[e-ric]

Sur les gros projets, je crée un DataModule qui représente la base de données puis un DataModule par table. Ils sont créés / détruits dynamiquement au fur et à mesure des besoins

Effectivement, c'est encore plus poussé que ce que je propose mais cela ne génère-t'il trop de fichiers source ? J'aurais plutôt tendance à regrouper les tables dans des modules de données selon leur affinité fonctionnelle.

Comment fais-tu pour les tables reliées ensemble (relation maître / détail, lookup) ? Tu dois être amené à faire pas mal de code pour gérer tout cela, as-tu prévu des automatismes ?

Cordialement

e-ric

[Bloon]

Effectivement, c'est encore plus poussé que ce que je propose mais cela ne génère-t'il trop de fichiers source ? J'aurais plutôt tendance à regrouper les tables dans des modules de données selon leur affinité fonctionnelle.

Ca fait beaucoup de fichiers effectivement, mais ça n'est pas du tout gênant.

Comment fais-tu pour les tables reliées ensemble (relation maître / détail, lookup) ? Tu dois être amené à faire pas mal de code pour gérer tout cela, as-tu prévu des automatismes ?

D'où l'intérêt de la POO, tu programmes une fois le comportement maitre/détail ou lookup et ensuite tu n'as plus qu'à l'utiliser partout où tu en as besoin. Ca permet d'écrire des choses du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// Liste des commandes d'un client
// client et commande sont des objets "metier"
client.ajouteLiaison(TLiaison.Create(TCommande,'CLIENT'));
...
commande := client.getLiaison(TCommande).getObjet;
...
dataSourceCommande.DataSet := commande.datamodule.getDataSet;

C'est difficile d'entrer dans le détail dans un post de forum :-)
Bloon

[kase74]

Bonjour, je contribue modestement en faisant part de mon experience :

Comme Malatar, j'ai prefere creer un DM generique qui comporte le TSQLConnection et les grosses tables communes.
Puis, je cree dynamiquement un DM propre a chacune de mes form pour les acces complementaires. Je n'ai eu aucun souci avec les relations maitres-details.

PS : bloon, je ne comprends pas ce que tu veux dire avec

je crée un DataModule qui représente la base de données

. Tu as deja tout a ce moment la ?

[Bloon]

PS : bloon, je ne comprends pas ce que tu veux dire avec

je crée un DataModule qui représente la base de données

. Tu as deja tout a ce moment la ?

Je veux dire qu'il représente la connexion à la base de données et qu'il sera utilisé par les autres datamodules pour effectuer des requêtes sur la base.

Bloon