Discussion :

[Atsibat]

Bonjour à tous,

je planche sur un éventuel mapping des données qui me permette de passer d'une base à une autre sous différents SGDB.
Pour le moment j'envisage quelque chose qui ressemble à ceci :

Code :

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

1
2
 
oBase["nomBase"].oFichier["nomFichier"].oRubrique["nomRubrique"].val="valeur"

qu'en pensez vous? Utilisez vous un système de mapping et si oui quel est il ?

merci d'avance pour vos réflexions.

[tatayo]

Bonjour,
Actuellement nous n'utilisons rien de tel, mais c'est en projet.

J'ai dans l'idée de masquer complètement l'accès à la base dans des classes.
Ainsi les applications ne feront qu'interagir avec ces classes, sans savoir ce qu'il y a derrière, sans accès direct à la base.
Par exemple pour afficher un article:
1. Instanciation de l'article
2. Affectation de son code à la propriété "code" de l'objet
3. Affichage des infos via le databinding, en utilisant les propriétés de la classe

Le chargement des données se fait directement dans la classe, lors de l'affectation du code, ou lors de l'accès en lecture à une propriété (pour ne charger que les données effectivement utilisées). Idem pour les mises à jour.

Donc au final l'application ne sait rien de la base, du schéma des tables... elle ne voit que des objets.

Mes premiers tests, sous forme de POC sont assez concluant, mais malheureusement pour l'instant ça reste un POC pour cause de planning "débordant".

Quelques nouveautés de la 17 (et demain la 18) devraient d'ailleurs m'aider dans cette tâche.

Tatayo.

[Atsibat]

He voilà c'est exactement la même problématique chez moi.

En fait je me base sur le pattern DAO que j'utilisai en java et qui correspond à ce que tu écris.
Par exemple dans un logiciel de gestion j'ai des factures avec des ID_Fact.
Dans un logiciel de BSI où je fais des stats j'ai aussi une table factures mais certaines rubriques sont en plus et d'autres en moins.
De plus je ne souhaite pas avoir une analyse WD sur le logiciel de BSI.

je pourrai donc faire une classe DAO générique
puis une classe DAO_Facture héritant de DAO
puis deux classes DAO_FactureGest et DAO_FactureBSI héritant de DAO_Facture

Ensuite je reécris les fonctions de CRUD pour DAO etc...
mais au départ celà me semble très long d'écrire mes classes et je me demande si je ne suis pas en train de reécrire un truc inutile...

L'autre approche serait de faire une classe cConnexion
puis une classe cBaseDB avec un membre cConnexion
et un membre tableauDeFichierDB

puis une classe cFichierDB avec un membre tableauDeRubriqueDB

puis une classe cRubriqueDB avec un membre mValeur et mType

du coup pas d'autocompletion possible mais beaucoup moins de classes.

le workflow est du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
maBaseBSI est un cBaseDB 
maBaseBSI .ouvreConnexion()
maBaseBSI .implemente("Facture","ID_Facure","valeur")
// ce qui se traduit par : maBaseBSI .tblFicDB["Facture"].tblRubDB["ID_Facure"].val="valeur"
maBaseBSI .implemente("Facture","PUHT","123")
maBaseBSI .implemente("Facture","QFACT","5")
...
...
maBaseBSI .sauve("Facture")

On a la mauvaise impression de re-écrire les fonctions de WD mais dans l'idée celà permet de se de-solidariser de la base et donc d'attaquer des bases qui ont mutées ou de version différentes à la seule condition que les noms de table et rubriques utilisés dans le coeur n'aient pas changé.

J'aimerai savoir quelle approche est la meilleure? ou si aucune quelle approche adopter?

A.

[Emmanuel Lecoester]

cela me rappelle un vieux projet sur lequel j'ai participé...

Pour avoir trempé là dedans j'ai une question toute simple : quel est l'intéret pour vous ? : ouvrir les fonctions à de nouvelles bases, ouvrir sur des bases non supportées par l'éditeur (au final il y en a très peu vu que l'accès OLE-DB reste possible) ?

[Emmanuel Lecoester]

J'aimerai savoir quelle approche est la meilleure? ou si aucune quelle approche adopter?

Si tu souhaites te passer de HF, une technique présentée ici me semblait pas mal : avoir une analyse pour avoir la complétion automatique, faire un HFermeConnexion() et tout développer en ordre SQL avec un sqlconnecte. C'est compatible toute base de données (même HF) et tu te bases sur un accès ole-db ou odbc.

[Atsibat]

Emmanuel : merci pour ta réponse, c'est déjà plus ou moins comme ça que je fonctionne. C'est comme ça que je me suis d'ailleurs rendu compte que l'accès aux fichiers de l'analyse et les fonctions H*** correspondent à peu de chose près à une couche DAO made in PC SOFT.

Mais l'impossibilité actuelle de déclarer un fichier dans un objet (ça serait drôle on ferait un truc comme monTuple est un Facture) due probablement à une hypertrophie du WD langage qui désigne à la fois un tuple ET toute la table sous le même nom doit poser quelques difficultés chez nos amis dev de PCSOFT.

Donc en procédant comme tu le décris (et c'est déjà assez confortable) on se trouve toujours limité à un moment par un oscur parcours du genre :
{"nomFichier.nomRubrique"}="valeur"
Ce qui fonctionne très bien mais qui coute cher en temps de réflexion six mois plus tard pour se souvenir de ce qu'on appelle exactement...

d'où l'idée d'aller un cran plus loin.

Secondement pour vous répondre (car je me pose aussi la question tous les jours) celà me sert dans l'optique ou ma base est appelée à évoluer en dehors de mes développements. Je travaille avec une base SQL SERVER sur laquelle le client peut créer ses tables et ajouter des champs dans les miennes. Chaque base étant potentiellement différente pour chaque client. La seule chose sur laquelle je m'appuie est un certain nombre de tables et de rubriques qui sont dans le coeur de mon application et qui ne changeront pas.

Alors mon programme fonctionne bien avec le coup du hfermeAnalyse au départ et un hdeclareFichiers pour tous les fichiers mais je me demande si il n'y a pas une façon plus propre de travailler...

merci en tout cas

[tatayo]

On a plusieurs raisons pour passer à cette architecture:
1. Séparer complètement la partie "interface utilisateur" de la partie "accès aux données". Je l'ai fait dernièrement pour l'accès à l'API de Magento: cette API est complètement masquée par des classes, le tout dans un composant.
Celà simplifie largement l'utilisation de l'API, et tout changement de celle-ci est transparent pour les applications utilisatrices.

2. Historiquement, nos applications s'appuie sur une base dont le schéma est "déduit" de l'interface d'import/export de notre ERP. Or nous allons changer celui-ci, et réintégrer une partie des données dans le nouveau. On va également ajouer un PIM. de fait les données actuellement dans une base seront éclatées dans 3 bases différentes. Et on doit tout réécrire.
Si on avait fait cet effort avant, seule la couche "accès aux données" aurait été modifiée, pas le reste des applications.

Alors effectivement, au début on a l'impression d'écrire du code mort, mais une fois cet effort fait l'écriture des applications va bien plus vite.

Tatayo.

[Emmanuel Lecoester]

Dur de répondre à vous deux en même temps

@Atsibat et tatayo : le fait de ne voir qu'une partie de la base de données n'est pas dérangeant. Cela le devient si on accède depuis WinDev à une table qui a évolué (ajout de colonne ou suppression de colonne). Si c'est une suppression : ben pas grand chose à refaire hormis relivrer l'application, si c'est un ajout de colonne avec des valeurs par défaut : rien à faire, si le colonnes sont en not null sans default value, il faut relivrer.
Cet argument (évolution de colonnes de table) vaudra aussi quelques soit votre technique : il faut toucher à quelque chose dans votre application.

@tatayo : pour le point 1 ok on fait abstraction des données mais WinDev n'a pas vocation à faire du MVC . C'est tout le contraire en fait

@tatayo : pour le point 2, je ne sais pas si on peut indiquer dans l'analyse différente sources de données (Oracle et Access par exemple). Si ce n'est pas possible, ben je ne vois pas comment faire et comment vous pourrez faire avec une autre solution (quid des requetes entre ces deux environnements ?)

J'espère vous aider

[tatayo]

Disons qu'on n'a pas d'analyse, tout passe déjà par des requêtes SQL et des ordres Sql*.
Dans la prochaine archi, tout sera sur SqlServeur, donc on pourra faire des requêtes multi-bases (au besoin en utilisant des serveurs liés).
Dans notre cas on ne parle pas d'une colonne en plus ou en moins, mais d'une refonte total. Bon, j'avoue que ça n'arrive pas tout les 4 matins non plus

En fait le but derrière est de factoriser au maximum le code: les ordres de CRUD d'un client ne se feront qu'à un seul endroit: dans la classe client.
Le tout dans un composant utilisé par toutes les applis internes.

Tatayo.

[Atsibat]

Après une bonne nuit la solution évidente me paraît d'écrire les classes pour chaque entité. donc solution n°1 : (cFacture, cClient, cReglement etc...

une classe DAO générique
puis une classe DAO_Facture héritant de DAO
puis deux classes DAO_FactureGest et DAO_FactureBSI héritant de DAO_Facture
Ensuite je reécris les fonctions de CRUD pour DAO etc...

Et puis en y réfléchissant j'ai choisi cette approche :
- créer un projet vide,
- créer une analyse automatique en retro-modelisation sur la base de donnée existante
- Créer une description UML et un diagramme de classe
- Créer automatiquement mes classes à partir de l'analyse
- Renommer mes classes
- Importer les classes renommées dans le projet initial.

De cette façon je pars avec déjà la majorité de mes classes écrites et bien membrées si vous me passez l'expression.

Vous me direz que j'aurai pu le faire dans le projet de départ mais cette manip déstabilise pas mal le projet et j'ai déjà souffert de la gestion automatique de l'UML dans WD donc je préfère le faire en deux fois.

Il me semble d'ailleurs qu'Emmanuel utilise volontiers le modèle UML de WD mais j'avoue ne pas être très à l'aise avec cet outil.

[Atsibat]

Pour le coup du MVC j'étais plutôt d'accord avec Emmanuel mais en avançant dans cette direction (se passer de l'analyse) et en éliminant progressivement les procédures locales puis globales je me suis rendu compte que le modèle de séparation se dessine de lui même presque malgré moi.

Donc WD n'a pas de vocation particulière à faire ou à ne pas faire, c'est vraiment un problème d'architecture globale.

J'ajoute cependant que le choix de la POO dans WD nécessite un effort pour ne pas tomber dans la facilité des procédures telles qu'on les mets en place dans nos mini dev WD.

Il faut partir des postulats suivants :
Si vous devez écrire une proc locale c'est qu'un de vos champ d'IHM n'est pas exploité sous forme de variable.
Si vous devez écrire une proc globale c'est qu'une opération récurente à plusieurs composants d'IHM n'est pas exploité dans un objet
Si vous avez une variable globale c'est qu'il manque un membre à un objet ou qu'il manque un objet à votre modélisation.
Donc la présence d'une Proc ou Variable orpheline témoigne toujours d'un défaut de modélisation.

De la même manière je considère que dans 90% des cas une ligne de commentaire témoigne d'une faute de codage (en général nommage ambigu)
mais c'est un autre débat.

Il faudrait donc écrire une version du programme en tolérant les proc et variables.
Pui re-écrire le programme en éliminant progressivement ceux ci.

Je me suis un peu écarté du sujet là. désolé.

[Emmanuel Lecoester]

En fait mettre les crud au niveau des entités c'est exactement le point de départ du projet de 2001 R&B s'en souvient très certainement.

Si le point de départ est de se passer d'une analyse, je comprends mieux votre volonté de revenir sur des fondamentaux une classe par table. Mais bon... si vous partez en CRUD le full SQL c'est fini...

Je ne sais pas si vous avez déjà explorer cette technique :
- import de la base de données distante dans votre analyse
- surcharge des fonctions Hxxx dans une collection de procédure
- adaptation du code pour mettre ce que vous voulez en fonction de paramètre globaux du style

Code :

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

1
2
3
4
5
Si modeHF alors
   HLitRecherche...
Sinon
   MaMéthodeAMoiQuiAccèdeASQLServer...
Fin si

[Emmanuel Lecoester]

Pour le coup du MVC j'étais plutôt d'accord avec Emmanuel mais en avançant dans cette direction (se passer de l'analyse) et en éliminant progressivement les procédures locales puis globales je me suis rendu compte que le modèle de séparation se dessine de lui même presque malgré moi.

Donc WD n'a pas de vocation particulière à faire ou à ne pas faire, c'est vraiment un problème d'architecture globale.

J'ajoute cependant que le choix de la POO dans WD nécessite un effort pour ne pas tomber dans la facilité des procédures telles qu'on les mets en place dans nos mini dev WD.

Il faut partir des postulats suivants :
Si vous devez écrire une proc locale c'est qu'un de vos champ d'IHM n'est pas exploité sous forme de variable.
Si vous devez écrire une proc globale c'est qu'une opération récurente à plusieurs composants d'IHM n'est pas exploité dans un objet
Si vous avez une variable globale c'est qu'il manque un membre à un objet ou qu'il manque un objet à votre modélisation.
Donc la présence d'une Proc ou Variable orpheline témoigne toujours d'un défaut de modélisation.

De la même manière je considère que dans 90% des cas une ligne de commentaire témoigne d'une faute de codage (en général nommage ambigu)
mais c'est un autre débat.

Il faudrait donc écrire une version du programme en tolérant les proc et variables.
Pui re-écrire le programme en éliminant progressivement ceux ci.

Je me suis un peu écarté du sujet là. désolé.

Cà pourrait faire un bel article : développer une application WD en mode MVC.

[tatayo]

Si le point de départ est de se passer d'une analyse, je comprends mieux votre volonté de revenir sur des fondamentaux une classe par table. Mais bon... si vous partez en CRUD le full SQL c'est fini...

Ce n'est pas tout à fait ça: je ne compte pas créer une classe par table, mais par "entité logique".
Par exemple un article ne sera composé que de 2 ou 3 classes, alors qu'il utilise une bonne dizaine de tables dans la base.

La suppression de l'analyse n'est pas un but en soit, mais vu que:
1. Je n'utilise pas d'ordre h
2. Je n'utilise pas le requêteur de Windev (bien trop limité)
3. Ma base est "répartie" en plusieurs schéma, avec des tables communes et des droits de lecture/écriture différent selon le role endossé par l'utilisateur
4. 100% des accès passent pas des ordres SQL
L'analyse dans Windev perd tout son intérêt.

En fait le point de départ de mon analyse est le suivant:
Dans notre organisation actuelle, si on a deux fenêtres, par exemple celle des tickets de vente et celles des articles, les critères de recherche portant sur les articles (pour trouver un article, ou un ticket en fonction des articles présents) sont peu ou prou les mêmes. Mais on a deux codes, et deux requêtes différentes. Si on enrichie la recherche des articles, celle des tickets n'en profite pas.
Donc en mettant l'accès aux données dans des classes qui "communiquent" entre elles, et en liant les champs de saisie des fenêtres à des propriétés de ces classes, le code se factorise de fait.
Et si on par exemple on affiche la liste des ventes dans la fenêtre des clients, plutôt que d'écrire une n-ième requête, on ne fait que lier un tableau d'objet ticket présent dans la classe client. La lecture de ce tableau déclenche la recherche via la classe "critère de recherche ticket", le tout sans écrire de requête.
Au final dans l'application l'affichage des tickets d'un client se résume à lier un tableau d'objets à un champ table. Aucune ligne de code n'est nécessaire.

C'est le test que j'avais mené à la sortie de la 16, et j'avoue que le résultat dépasse largement ce que j'en attendais.

Maintenant ce qui me manque pour la mise en prod, c'est du temps...

Tatayo.

[Atsibat]

- surcharge des fonctions Hxxx dans une collection de procédure

Code :

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

1
2
3
4
5
Si modeHF alors
   HLitRecherche...
Sinon
   MaMéthodeAMoiQuiAccèdeASQLServer...
Fin si

Génial ! je n'avais même pas pensé à surcharger une fonction H
c'est pourtant évident !!
Parfois les choses simples.....

Si j'ai une table CLient déclarée dans une analyse est il possible de l'intégrer un enregistrement en tant que membre d'un objet sans avoir à définir un objet cClient ?

merci en tout cas.

[Emmanuel Lecoester]

Si j'ai une table CLient déclarée dans une analyse est il possible de l'intégrer un enregistrement en tant que membre d'un objet sans avoir à définir un objet cClient ?

Non c'est pas possible... il faut que tu te chopes le mapping à la main. Donc il te faut deux tableaux : un pour le nom des colonnes, un pour la donnée