La POO peut elle se revelée utile dans le cadre d'une base de donnée ??

La question est vide de sens (au sens ou elle est trop generale), je le reconnais.

Mais je pose malgre tout la question parce que si quelqu'un y voit un interet, ca peut m'interesse aussi !!!

Dans quel cadre avec du concret (a l'inverse de ma question), quel gain,, a quel niveau ( conception, dev, lecture du code ...)

Bref je me demande si je dois m'investir dans cette philosopie de pensée ou pas.

Faites vivre ma reflection, je voudrais me faire une opinion .

Merci pour vos réponses.

Bon dev a tous

La question n'est pas aussi vide de sens qu'il n'y parait !

Depuis peu, le Wlanguage propose les commandes fichierversmémoire() et
memoireversfichier() qui comme elle le laisse entendre permettent stocker en
mémoire le contenu d'un enregistrement et de sauvegarder le contenu d'un
enregistrement en mémoire vers le fichier.
Ces commandes utilisent des objets (ou des structures) pour sauver
l'enregistrement en mémoire.

Dès lors on peut imaginer de nombreuses utilisations pour ce mécanisme ...

En effet, si WD, en natif utilise déjà des buffers en mémoire pour stocker
les informations liées à un fichier puisque pour écrire physiquement dans un
fichier, il faut utiliser un Hajoute() ou un Hmodifie(), sauf à utiliser des
alias, on ne peut conserver en mémoire, à un moment donné, qu'un seul
enregistrement d'un fichier à la fois ...

Comme on peut instancier autant d'objet que la mémoire le permet, on
pourrait imaginer de pouvoir stocker en mémoire un nombre indéterminé
d'enregistrements dans des objets (ou structures) ...

Bon ... il faut bien avouer que l'utilité de ceci n'est peut-être pas
immédiatement perceptible ...

Néanmoins, imaginons une application client serveur qui permet d'afficher un
enregistrement et de le modifier.
On peut imaginer que plusieurs personnes tentent de modifier cet
enregistrement simultanément ...
On peut, avant d'enregistrer les modifications, relire l'enregistrement sans
faire de fichierversecran() afin de vérifier si les données affichées sont
différentes de celles présentes dans le fichier.
Mais comment savoir si les données du fichier sont bien celle qui ont été
lues à l'origine ?
C'est là qu'un objet stockant l'état de l'enregistrement au moment de la
lecture initiale pourrait être utile ...

Par ailleurs, nous pouvons utiliser des triggers et des procédures stockées
au sen de notre application afin d'appliquer des règles métiers (business
rules) ...
Néanmoins dans certains cas, un objet qui dispose de méthodes permettant de
valider un enregistrement et de l'enregistrer peut avantageusement remplacer
des procédures de validation avec un avantage supplémentaire, c'est que si
on utilise l'objet partout dans l'application, on est sur que la règle est
bien appliquée partout de la même manière, puisque le code est centralisé
une fois pour toute dans l'objet qui gère cette famille d'enregistrements.
Enfin, et ce n'est pas négligeable, les objets peuvent être modélisés (UML)
avant leur écriture et mis à jour au fur et à mesure de l'évolution de la
classe ... ce qui,quand on doit expliquer la structure d'une application,
peut faire gagner énormément de temps ...

C'est donc une question qui ouvre la porte à de nombreuses questions et qui
débouche sur LA question fondamentale :
Voulons-nous modéliser notre application avant de commencer à l'écrire ?
Si oui, je pense que des objets liés à la base de données peuvent être
utiles ...
Outre les avantages d'une bonne modélisation, de la réutilisation du code et
d'une centralisation du code, l'utilisation d'objets permet, à mon sens
aussi, une plus grande facilité dans les développements en équipe.
Pour autant que les divers intervenants comprennent et utilisent la POO,
chacun ne devant connaître que les membres et les méthodes publiques,
l'utilisation d'un objet "enregistrement de fichier" plutôt que le travail
direct sur l'enregistrement, me semble augmenter considérablement la
fiabilité d'une application.


C'est mon opinion en tout cas !