Discussion :

[mathias]

Bonjour,

J'aimerais avoir votre avis de programmeur. Je veux me créer une classe qui va gérer une table. Et je vais utiliser une instance de classe dans un formulaire indépendant pour gérer le contenu de la table. Donc, la classe aura ses propriétés (les champs de la tables) et ses méthodes (ajouter, modifier, rechercher, supprimer, etc.).

Pour les méthodes d'ajout et de modification, comment vous déclarer votre méthode. Est-ce que vous passez tous vos valeurs à assigner dans vos champs en paramètres (Ex : objet.ajouter(champs1, champs2, champs3, champs4) ). Donc quand on fait un ajout, on doit passer toutes les valeurs des champs en paramètres.

Ou vous préférez faire au préalable attribuer à vos valeurs à chacune de vos propriétés de l'objet et ensuite appeler la méthode d'ajout. Ex :

objet.champs1 = "valeur"
objet.champs2 = "valeur"
objet.champs3 = "valeur"
objet.champs4 = "valeur"
objet.ajouter()

C'est un peu le même principe dans le cas d'une modification.

Donc j'aimerais avoir votre avis. Quelle méthode préconisez vous ?Laquelle vous préférez? Y-a-t-il des avantages, des inconvénients, etc.

Merci pour vos réponses.

[vmolines]

Le modèle objet access (DAO) implémente déjà un peu ce que tu veux faire à l'exception près que tu ne disposes pas de l'auto complétion dans l'éditeur de code car les noms de table et de champ ne lui sont pas connus.

Je te conseille de jeter un coup d'oeil ici pour commencer : http://warin.developpez.com/access/dao/

Ensuite rien ne t'empèche d'encapsuler la bibliothèque d'accès aux données DAO dans tes classes pour bénéficier de tout ça.

[random]

comme vmolines l'a justement souligné dao offre tout ça en natif
de plus il est aussi possible d'ajouter des propriétés perso avec access


ceci étant avant d'ajouter un champ il faut connaitre le type
de données qui fait référence au type de valeur

pour celà on peut s'inspirer de ce que fait l'assistant import en création de table

j'espère que tu fais tout ça à titre ludique parceque au niveau efficacité
l'exploitation de l'existant est plus robuste

à moins que tu nous prouves que ta classe ajoute une réelle plus value
par rapport au mode interactif ou aux modules dao

bonne chance

[Tofalu]

De plus, si tu ajoutes un champ à la table, il te faut ajouter une propriété à la classe ...

Pour moi, c'est réinventer la roue. Créer une classe qui fera la même chose qu'un reocrdset (et qui utilisera de toute façon les recordsets), c'est ajouter une surcouche inutile multipliant inévitablement les erreurs et diminuant la stabilité de l'appli

[random]

pas nécessairement Tofalu si la classe table comprend une collection de champs



tabledef ne fait rien d'autre

mais sur la vanité de la chose je suis assez d'accord

ceci étant ceci peut avoir un caractère pédagogique très favorable

[Tofalu]

Le seul avantage que j'y voyait c'était le même que vmolines à savoir l'autocompletion. Si il implémente une collection, il perd l'autocompletion.
C'est pour ça que je pensais qu'il voulait une propriété par champ :

Donc, la classe aura ses propriétés (les champs de la tables)

ceci étant ceci peut avoir un caractère pédagogique très favorable

ça c'est certain

[random]

ben il peut toujours avec son programme ajouter une propriété dans
sa classe

il suffit d'écrire dans le module même

vous voyez bien que ça pourrait être très ludique...

[mathias]

Re-bonjour,

Excusez-moi si cela a pris quelques jours avant de répondre. Mais j’ai pris le temps de lire vos réponses et de consulter le tutoriel suggéré par vmolines.

Premièrement, je comprends vos réponses. C’est vrai qu’à première vue, cela semble inutile de re-créer une classe qui va gérer le contenu d’une table pour une utilisation dans un formulaire indépendant. A chaque fois qu’on re-créé un nouveau champs dans la table, il faut ajouter une propriété à l’objet. On alourdi la gestion du programme. On serait porté à croire qu’un bon vieux recordset branché sur le formulaire et le tour est joué ! C’est peut-être aussi le cas. C’est le but du message, je veux poursuivre la discussion afin d’avoir l’avis d’un peu tout le monde.

Je reprends un peu mon idée du départ. Je veux utiliser au maximum des formulaires indépendants (que je trouve plus flexibles et utiles en environnement multi-usager). Pour ce faire, certains formulaires ne seront branchés qu’à une seule table. Je voulais monter une classe qui pourrait gérer le contenu de la table (qui est en fait un recordset qui peut utiliser des méthodes d’ajout, de modifications, de recherche, de suppression. Les propriétés représenteraient les champs de la table). C’est vrai qu’à première vue, l’utilisation d’un simple recordset serait plus rapide. Mais je me disais qu’en utilisant une classe, On implémentait la logique de fonctionnement d’une table à un seul endroit. Donc si j’ai besoin ailleurs dans le programme d’effectuer une recherche dans ma table. Pas besoin de recoder un nouveau recordset, de faire un findfirst, de valider s’il trouve ou non , etc Tout serait déjà implémenter dans la classe et je n’aurais qu’à me créer un instance de la classe et le tour est joué. C’est vrai par contre que si on décide de créer des nouveaux champs, cela implique des modifications à faire à la classe (nouvelles propriétés, modifier les méthodes d’ajout et de modification, etc.) C’est le prix à payer si on utilise ce mode de fonctionnement. D’autant plus que j’aurais certains formulaires qui feront de la saisie de données dans plusieurs tables reliées entres elles. Je me disais que l’utilisation d’un objet ‘master’ serait payante à ce moment car je n’aurais qu’à utiliser les classes des tables que j’ai créé au préalable.

Concernant le tutoriel de DAO, j’ai vu qu’il était possible de rajouter des propriétés à une tables. Je ne suis pas certains d’avoir tout compris le fonctionnement. En quoi cela peut-il être bénifique et comment puis-je l’intégrer à ma logique ?

Que pensez-vous de tout ça ? Est-ce que ça éclaircit un peu les raisons pour lesquelles je songeais à envisager cette approche ? Ne vous gêner pas pour laisser vos commentaires. Je suis ouvert aux suggestions.

Merci à l’avance.

[cafeine]

Hello,

ce que je ne pige pas c'est comment au bout du compte tu vas accéder à la table ?
ta classe rajoute une couche sur ADO / DAO ?

Je ne comprends pas vraiment l'argument des formulaires indépendants, ça change quoi ?

Si tu veux vraiment ajouter des fonctions évoluées et des routines à DAO, rien ne t'empêche de coder des fonctions avec des recordsets en argument ...

[mathias]

Salut Caféine,

Effectivement, ce qui va arriver en bout de code, c'est que je développerais une couche d'objet qui contiendrait la logique métier de mon appli. Donc, je cherche à créer des classes qui vont gérer le contenu des tables, contenir la logique métier et mes formulaire feront appels à ces objets.

Il ne faut pas oublier que le but de la classe n'est pas que d'accéder aux données. La classe va gérer beaucoup plus de choses et augmenter la cohérence selon les cas particulié des tables. Je veux aussi avoir des objets qui vont travaillers dans plusieurs tables simultanément.

De ce que je peux voir, il est difficile d'exprimer ce que je cherche à faire. J'espère que ces précisions éclaire un peu plus ...

[random]

Bon c’est quoi les traitements métiers ?
1 constitution des données : import, saisie, modification, suppressions des données et codifications ceci est parfaitement commun à tous les métiers, en remplaçant le nom de colonne machin par truc.
2 gestion des données (définition du type des champs, intégrité, clef, indexation, clauses de validité, champs calculés ) ceci est parfaitement commun à tous les métiers, en remplaçant le nom de colonne machin par truc. On trouvera quelques différences spécifiques particulières, (la sécurité nécessaire n’est pas nécessairement de même niveau dans l’aéronautique et dans la fabrication des patins à roulettes) qui se surmontent facilement en montant d’un cran dans l’abstraction.
3 traitement des données si on remplace les calculs par fonction(champ0..champn) ceci est parfaitement commun à tous les métiers, en remplaçant le nom de colonne machin par truc.
4 restitution des données : (requêtes, report, formulaires, graph, backup…) ceci est parfaitement commun à tous les métiers, en remplaçant le nom de colonne machin par truc.

Le fond du métier serait donc le vocabulaire et il suffit de remplacer machin par truc pour tous les unifier (au niveau logique).

Donc au niveau d’abstraction nécessaire au traitement métier, un sgbd digne de ce nom répond à tous les besoins, avec des nuances relatives au volume, et des fonctionnalités plus ou moins étendues.

Access propose en natif, de très nombreux outils (plus qu’il n’est le plus souvent nécessaire) permettant cette gestion, soit en mode interactif soit en mode programmation.

On peut toujours créer le méta langage d’un langage, mais on ne peut pas indéfiniment reculer le niveau d’abstraction (carré blanc sur fond blanc est du domaine de la subversion, et la boucle d’oreilles à l’oreille de la vache qui rit (salut Ô Rabier) finit au pixel)

Je veux bien qu’on écrive des classes pour prendre en charge des classes existantes, ou qu’on se serve d’une cuillère pour tenir la cuillère avec laquelle on va manger sa soupe, mais je trouve cela peu commode.

Quand dans une base on trouve des invariants, on s’interroge sur la fusion des objets invariants, on crée une fonction, ou on se contente de modifier la source (parfois le philtre d’un objet), sans écrire une classe d’encapsulation des objets existants.

Pour résumer je trouve, et j’espère que tu me pardonneras cette appréciation aussi franche que discourtoise, ta démarche aussi sympathique que naïve, et si tu as besoin d’aide je veux bien t’aider sur des problèmes concrets.

Cependant quand tu auras fini ta cathédrale (ou usine à gaz), il faudra te poser la question suivante « Comment écrire une classe permettant de manipuler mes classes ? ».

[Tofalu]

Surtout que la couche que tu vas impémenter sera forcément moins stable que DAO puisqu'elle utilisera DAO. En ajoutant une couche à une chouche à une couche, on augmente la complexité, on réduit les perfs, on diminue la stabilité, on augmente les temps de développement.

On implémentait la logique de fonctionnement d’une table à un seul endroit. Donc si j’ai besoin ailleurs dans le programme d’effectuer une recherche dans ma table. Pas besoin de recoder un nouveau recordset, de faire un findfirst, de valider s’il trouve ou non , etc

Mouais, sauf que si deux formulaires utilisent ton même objet, une navigation dans un apportera une navigation dans l'autre. A moins de créer une copie, mais je n'en voit pas l'intérêt. D'autant plus que si tu instancies 10 tables de de 100 Mo au début de ton appli pour en disposer tout le temps, bonjour les perfs

Donc, je cherche à créer des classes qui vont gérer le contenu des tables, contenir la logique métier et mes formulaire feront appels à ces objets.

C'est déjà le cas des recordsets

Qu'est ce qu'il te manque au niveau des recordsets pour pouvoir les utiliser ?

Concernant le tutoriel de DAO, j’ai vu qu’il était possible de rajouter des propriétés à une tables. Je ne suis pas certains d’avoir tout compris le fonctionnement. En quoi cela peut-il être bénifique et comment puis-je l’intégrer à ma logique ?

Cela permet de stocker des données relatives à la tables et non enregistrements... des propriétés quoi ... On pourrait trés bien y gérer un nombre d'enregistrement maximum, etc. Bien sûr le test de ces propriétés n'est pas géré par le moteur de base de données mais par la couche applicative (en effet, pas de trigger sous access).

Il ne faut pas oublier que le but de la classe n'est pas que d'accéder aux données. La classe va gérer beaucoup plus de choses et augmenter la cohérence selon les cas particulié des tables. Je veux aussi avoir des objets qui vont travaillers dans plusieurs tables simultanément.

Là OK, mais on est pu au même niveau que ta question initiale qui consistait a recoder un moyen d'accès au table.

Bien entendu, on peut avoir une classe voiture, dont la méthode Louer va écrire dans la BD que le champ loué est égale à True. Bien entendu on peut avoir une classe lesvoitures avec une méthode ListeVoitureLibre ... Mais pour ça rien de nouveau ni de rapprochant avec ta question initiale. Avoir une couche métier oui, redévelopper une couche SGBD, bof