Discussion :

[eponette]

Je cherche un bon, moyen de séparer mes données de mes objets métiers. Dans la section design, ils m'ont dit d'uitliser la pattern DAO. Mais comment implémenter cela en Delphi? Comment séparer la visuel (Form), les données (SQL, DataSource,...) et les objets métiers?

Je suis intéressé par vos expérience pour que je puisse trouver ma voie.

[DMO]

Bonjour,

En réponse je ne parlerais pas de DAO, mais comme tes questions font référence à de nombreuses notions, je ne peux pas te répondre entièrement. Cela ne m'empeche pas de tenter une brêve réponse, complètement incomplète, mais qui te suggère quelques pistes à explorer par toi même, ou sur lesquelles tu pourras poser des questions plus précises.

Le simple fait que tu te poses ces questions là prouve déjà que tu es sur la bonne voie (selon moi !).
Tu parles d'un modèle de conception. Celui que j'utilise très souvent, et qui est le plus connu, très simple à comprendre : le modèle observateur. Je ne me colle pas à l'explication, puisque de nombreuses personnes l'ont très bien fait avant moi.
Par exemple, tous les contrôles visuels orientés donnée dans delphi en sont de fabuleux exemples.
Sur le même principe, lorsque tu construis ton IHM, il faut (dans la mesure du possible car souvent certains contrôles mélangent tout...), te dire : "tiens si un jour je change tel contrôle par tel autre, il ne faudrait pas que j'aie à changer tout mon code". La gestion des données doit idéalement rester indépendante de l'affichage.
Parfois, cela peut se faire très simplement, dans une form, les éléments devant gérer les données de l'application sont des propoerty que tu as ajouté à ta form, les contrôles posés dessus servent à l'affichage et l'edition de ces property, dans toute l'application, tu ne travailles qu'avec ces propriétés, et seulement dans la form, aux moments opportins, tu appelles une procedure MettreAJourIHM par exemple, qui se charge de faire le lien. Ca te permet de n'avoir que cette procédure à modifier si tu changes ta facon d'afficher.
Dans des application non base de données, j'essaye de travailler avec 3 couches : persistance/métier/graphique : métier observe persistance, et graphique observe métier. J'évite de me perdre en explications ce serait trop long...
Concernant la persistance, je pense qu'il est important de dissocier la façon de faire persister, des classes à faire persister (Ex: ObjetAFairePersister.SaveToIniFile n'a rien à faire là, car si je le veux en xml ou autre...). Pour cela, je te conseille une utilisation absolument abusive des mécanismes RTTI. Cela offre une façon générique de faire persister, et permet la persistance sous toutes les formes souhaitables.
bon dernière chose, et j'arrète là, cet article qui vient de sortir est très interessant car il parle d'une des notions qu'il est important d'avoir (et que tu as surement déjà donc c'est juste au cas où) : http://neil.developpez.com/delphi/um...n-composition/

Bonne continuation.

Michel.

[eponette]

Je vais prendre un exemple simple et concret:

Dans mon application, il y a un form contenant des données d'une personne (nom, adresse,...).

Il y a aussi une table contenant les numéros de compte en banque de cette personne (ou société). Comme ce 'contact' (comme je l'appelle) peut en avoir plusieurs et dans plusieurs pays, j'ai mis cela dans un grid.

J'ai donc une classe comptebanquaire qui contient les info: NuméroDeCompte, Type de compte (local ou IBAN), pays du compte. J'ai aussi une classe validator pour valider le format du compte (car d'un pays à l'autre, c'est fort différent) et une classe presentator pour l'affichage correct du compte (je sauve les numeros de compte en DB sans formatage pour les transactions électroniques).

Donc maitenant, je suis un peu coincé pour ma grid. Car je ne veux pas faire un lien direct avec une DBGrid sur ma table comptebanquaire, car en plus la présentation est mauvaise. Comment faire communiquer ma classe CompteBanquaire avec une grid et toute en prenant les infos dans une DB?

Merci d'avance pour ton aide

[DMO]

À mon humble avis:

J'aime beaucoup ce qu'on peut faire avec des contrôles orientés données dans Delphi, à tel point qu'il m'arrive souvent d'utiliser des VirtualDataset pour mapper mes données non bases de donnée sous cette forme. Lorsque j'ai pour le coup de vraies bases de données, c'est donc avec plaisir que j'utilise les contrôles adéquats.

J'ai déjà, comme beaucoup, eu à développer une gestion de personne (au sens général du terme, ce que tu appelles contact, je l'appelle personne, et je décline en personne physique et personne morale). Effectivement ce n'est pas si simple, et la distinction que nous faisons est (sauf cas très simple) indispensable.

Suite à ton exposé, j'ai l'impression que tu t'embetes un peu trop en voulant faire bien :
Si toutes les données que tu dois gérer sont en base
Si ton application a un accès direct à cette base

Alors pourquoi ne

pas faire un lien direct avec une DBGrid sur

les tables dont tu as besoin ? Sachant que :
Dans un datamodule DmGestionContact par exemple, tu mets tous les datasets dont tu as besoin.
C'est dans DmGestionContact que tu fais tout le travail métier de ton application (vérification des saisies, rafraichissement des données, gestion transactionnelle, etc...)
La form devient ensuite une simple observatrice de
DmGestionContact. Tu branches les compos orientés données sur les datasource du datamodule, tu poses un actionlist avec des TDataSetPostAction, TDataSetEditAction, etc... et tu assignes les actions aux éléments que tu veux.
Penses aux évènements des TFields par exemple (OnValidate, etc...)
Si ce n'est que le DBGrid ne te plait pas, y'en a plein d'autres. J'utilise JvDbGrid (Jedi) par exemple.

Voilà c'est en gros ainsi que je ferais au vu des éléments que j'ai.

Bon courage (ou "amuse-toi bien" ça dépend comment tu le prends )

[eponette]

Merci pour ton aide