Discussion :

[apad]

Bonjour

J'utilise un data module pour placer mes composants d'accès aux données.
Mon datamodule contient désormais plus de 150 composants (dataset, datasource, ...) et ça commence à devenir difficile pour s'y retrouver (même en faisant preuve de rigueur dans le nom et la position des composants).

J'ai déjà exploré quelques pistes pour améliorer la lisibilité comme
1) Augmenter la résolution de l'écran, je n'ai plus d'ascenceur dans le data module mais j'ai les yeux qui piquent à la fin de la journée
2) Scinder mon data module en plusieurs data modules plus petits puis les instancier au sein d'un data module maître mais cette solution m'impose des contraintes techniques supérieures au problème de lisibilité.

Avez vous déjà rencontré ce problème et/ou connaissez-vous un composant graphique qui permettrait de regrouper dans un container un ensemble de composants (tels que les dataset et datasource) au sein du data module? Un datamodule graphique à l'intérieur du datamodule en quelque sorte.

Cordialement

[Aka Guymelef]

Bonjour,

pourquoi forcement instancier tout les DataModules par un DataModule maître ? Moi je scinderais chaque partie métier dans un DataModule distinct (tout les DataModule étant instanciés par défaut dans le DPR. Et ensuite dans le code je fais référence au bon DataModule contenant les DataSet / DataSource qui m'intéresse.

En plus le code va gagner en lisibilité (à mon sens) car les noms seront préfixés par le nom du DataModule qui, si il est assez explicite, pourra renseigné sur la nature du métier traité dedans.

[apad]

Je n'ai pas donné de détail sur les contraintes techniques rencontrées pour limiter la taille du post mais je me doutais bien qu'on allait me proposer de scinder le data module.

Merci pour cette proposition que j'ai déjà étudiée mais il se trouve que tous les datasets (les ClientDataSet pour être plus précis) sont liés à un dataset maître via la propriété DataSetField. Le dataset maître est utilisé pour stocker l'ensemble des données dans un unique fichier. Le simple fait de scinder en plusieurs datamodules entraîne quelques complications :
1) Impossible d'ouvrir le fichier si tous les dataset esclave n'ont pas été instanciés donc il est indispensable d'instancier tous les datamodules avant d'ouvrir un fichier.
2) Laisser le dpr instancier automatiquement les datamodules entraîne une consommation de ressource inutile si l'utilisateur n'ouvre pas de fichier. Les datamodules sont instanciées par la fiche qui utilise les données. Le datamodule maître permet de faciliter cette instanciation
3) A chaque montée de version du logiciel, le format du fichier est susceptible d'évoluer, il est donc nécessaire d'implémenter une procédure qui permette la compatibilité ascendante entre chaque version. L'application concerve donc un état du datamodule de chaque version pour garantir la compatibilité. La modification d'un dataset peut avoir des répercussions sur les autres datasets. En cas d'éclatement du gros datamodule, il est nécessaire de faire une gestion de version pour chaque petit datamodule.

Ce résumé rapide pour dire que je ne m'oriente pas vers un éclatement du datamodule. En fait, c'est ce que j'ai fait précédemment et j'ai fait machine arrière suite aux difficultés engendrées (notamment sur le point 3).

D'où la question sur le composant miracle ...

[ShaiLeTroll]

Voir DataModule ou pas ? , j'ai répondu à ce type de problème, et fourni des liens vers d'autres sujets relatifs à l'abus de composant dans un DataModule qui souvent amène à une abérration en terme de programmation objet, le métier n'étant pas encapsulé par des objets mais étant disséminé entre les Forms et le SQL sans lien et maitrise explicite (toujours se méfier de l'implicite)

Pourquoi ne pas tenter l'allocation dynamique des composants ? au lieu de tous les poser via l'IDE ?
D'ailleurs pour les relations genre MasterSource ... les affecter aussi en code ...

Pour le versionning, qu'appelle tu un "etat" ? une DFM stockée comme ressource quelque part ? le code d'allocation peut-être fait via un Script avec le scripter de Greatis TMS ou de Dream ...

[apad]

Merci ShaiLeTroll pour le lien mais pas vraiment adapté à mon contexte car :
1) Je n'accède pas à une base de données, donc pas de problème avec le SQL
2) L'allocation dynamique ça permet effectivement de limiter les composants visibles dans l'IDE mais si je les ai créé via l'IDE c'est justement pour bénéficier des facilités de l'IDE. J'ai pas trop envie de me palucher la création des datasets et des datafields à la main. En plus, les fiches utilisent des composants de contrôle de données (type TDBEdit et consort) et je n'ai pas non plus envie de renseigner manuellement les propriétés DataSource et DataField des composants.

Encore merci pour cette réponse mais si on peut s'éviter les posts du genre "Dites moi de quoi vous avez besoin, je vous dirais comment vous en passer"

Je reviens donc au sujet principal : le fabuleux composant container.
Bon, si il n'existe pas, je le développerai moi-même mais j'ai pas non plus envie de réinventer la roue ...

[ShaiLeTroll]

L'Allocation dynamique n'empeche pas d'affecter de DataField, c'est juste que tu n'as pas de liste te fournissant les champs existants, c'est à toi de bien savoir ce que tu tapes ... l'allocation dynamique peut créer juste les DataSets, tu peux très bien mettre les dataSource sur le DM (même si un DataSource finalement n'a d'utilité que sur la forme ayant des controles DB ... ou dans le cas de Relation Maitre-Détail)

Et ce composant container n'existe pas, d'ailleurs, comme les composants que tu utilise sont des TComponent, il n'ont pas de parent, donc tu n'y arriveras pas si facilement que tu crois surtout dans l'EDI ... car ce ne sont pas des composants ancrables c'est l'EDI qui simule de comportement avec le TContainer, sa classe interne lié à l'état Designing ...

Sinon, tu confonds Delphi avec un Clicodrome ... on ne fait pas ce que l'on a envie, on fait ce pour ce que l'on est payé de faire, et autant le faire bien ! Personnellement, je n'utilise plus de DataModule lui préférant un MVC avec un ensemble d'objet métier et objet système gérant ces objets métiers ...

[Rayek]

Pour ma part, dans le DataModule, je ne mets que les composants TxxxTable ou TxxxQuery.
Les Datasources, eux, sont toujours dans la form qui va les utiliser ou dans un Datamodule spécifique lié à cette Form.

Mais , bien sûr, chacun à sa méthode ^^

[apad]

L'Allocation dynamique n'empeche pas d'affecter de DataField, c'est juste que tu n'as pas de liste te fournissant les champs existants, c'est à toi de bien savoir ce que tu tapes...

Effectivement, mais ce n'est pas facile de se rappeler de tous les noms de champs lorsqu'ils sont nombreux. La liste des champs disponibles est quand même bien pratique.

tu peux très bien mettre les dataSource sur le DM (même si un DataSource finalement n'a d'utilité que sur la forme ayant des controles DB ... ou dans le cas de Relation Maitre-Détail)

J'ai plusieurs fiches différentes qui accèdent aux mêmes datasets. En mettant le datasource dans le datamodule, j'évite de créer un datasource sur chaque fiche.

Et ce composant container n'existe pas

Voilà enfin la réponse que j'attendais.

comme les composants que tu utilise sont des TComponent, il n'ont pas de parent, donc tu n'y arriveras pas si facilement que tu crois surtout dans l'EDI

Je ne me rappelle pas avoir écrit que je pensais y arriver facilement.

Sinon, tu confonds Delphi avec un Clicodrome

Je ne vois pas en quoi l'utilisation de la puissance de l'EDI serait un mal surtout au prix que le facture Borland.

... on ne fait pas ce que l'on a envie, on fait ce pour ce que l'on est payé de faire, et autant le faire bien !

Cette remarque est hors sujet. Par ailleurs, c'est un projet pour lequel je ne suis pas payé alors j'estime avoir le droit de faire ce que j'ai envie.

Personnellement, je n'utilise plus de DataModule lui préférant un MVC avec un ensemble d'objet métier et objet système gérant ces objets métiers ...

Pour reprendre la conclusion de Rayek : chacun à sa méthode

Merci de votre participation.
Cdlt