Discussion :

[rvzip64]

Bonjour,

J'ai une appli ou j'ai séparer la partie base de données de la partie affichage
J'ai mis tous les composant de ma base de données dans un TDataModule.

La question que je me pose est la suivante :

J'ai besoin d'effectuer une procédure qui va venir remplir une ListView, suite a une requte de ma DB.

Ou est qu'il faut que je mettre cette procédure ?
Dals le Datamodule ? ou dans la form qui gère l'Ihm ?

Merci d'avance pour votre réponse.

[chaplin]

Je dirais qu'il y a une troisième solution:
1) Soit tu mets ton code dans ton Datamodule
2) Soit tu mets ton code dans la fiche
3) Soit tu mets ton code dans une unité sous forme de classe et tu cherches
la classes la plus appropriée qui en sera le conteneur

En premier analyse, tu cherches à mettre ton code quelque part. Les deux possibilités que tu donnes sont des instances de classes.
Delphi a instancier à ta place les objets au moment ou tu as ajouté le datamodule et la fiche dans ton projet.
Le paradox, c'est que tu peux modifier le code sur une classe qui est instanciée.
Pas besoin de faire de Create ni de Destroy, l'EDI le fait à ta place (magie du RAD).

Un des fondamentaux de la POO, c'est de décomposer le problème en objets et les faire communiquer entre eux.
Si tu mets ton code soit dans le datamodule soit dans la fiche, tu vas avoir deux objets de plus en plus volumineux,
ou devrais je dire ton code vas gonfler les classes correspondantes.
Je dirais qu'un point de vue diététique tu vas rendre tes classes obèses.

Tu veux remplir une listeView à partir d'un Dataset, par conséquent tu créer une classe qui prend
en paramètre listview et le Dataset et dans laquelle tu mets tout ton code pour remplir ta Listview à partir du Dataset.
Ca ne t'empèches pas de créer une instance de cette classe dans la fiche.

Le datamodule est interessant lorsqu'il y a plusieurs Datasets dont certaines informations doivent être échangé entre eux. Il sert de médiateur.

[Just-Soft]

Salut;

Est ce que le DataModule fait appel à la fiche ? si c'est pas le cas alors le code sera implanté dans la fiche qui elle appelera le DataModule pour interagir avec la base de données.

En tout cas c'est ce que je fais le plus souvent.

Bon codage.

[Andnotor]

Chaqu'un aura son avis sur la question (plus ou moins difficile à comprendre )

Pars du principe que si la procédure de remplissage est étroitement liée au données du DataModule ou que plusieures fiches pourraient avoir besoin de cette procédure, inclus-la dans le DataModule. (Une seule source)

Même chose si différents projets pourraient en tirer parti (sur les mêmes tables). une seule unité à inclure.

Si la procédure permet de travailler avec différentes tables, crée une unité séparée.

Ne fait en tout cas pas référence à la fiche depuis le DatatModule. Tu te limiterais à une fiche particulière!

[chaplin]

L'idée c'était d'encapsuler l'algorithme dans une classe pour l'utilisation dans un autre cas de figure pas forcément dans le même projet.

Si une procédure peut résoudre la question en prenant en paramètre le dataset et la listview, on peut très bien envisager une classe.
Part héritage de celle ci, on peut très bien envisager des traitements variés même si le remplissage d'une listview par un Dataset semble être générique.

Disons que j'ai été marqué par du codage de masse dans le datamodule avec des procédures discéminées un peu partout et quand il faut débogguer le schmilblick, c'est pénible.

Cela dit je ne conteste pas la proposition Andnotor , j'ai fait attention de ne pas écorcher le nom

[Andnotor]

Si une procédure peut résoudre la question en prenant en paramètre le dataset et la listview, on peut très bien envisager une classe.

Et dans ce cas la meilleur classe serait un TDBListView.

... Andnotor , j'ai fait attention de ne pas écorcher le nom

Et je t'en remercie mon ami