|
Utilite de la POO/Base de donnée |
Débuté par andrianne jacky, 08 oct. 2007 18:18 - 5 réponses |
| |
| | | |
|
| |
Posté le 08 octobre 2007 - 18:18 |
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 |
| |
| |
| | | |
|
| | |
| |
Posté le 08 octobre 2007 - 18:44 |
andrianne jacky vient de nous annoncer :
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
si windev savait générer à partir du diagramme UML , les classes et les fichiers référents , ce serait génial. Hélas il s'arrête simplement au diagramme UML une adresse qui te donnera une petite idée des possibilités de la conception objet : http://www.dotnetguru.org/articles/Persistance/livreblanc/ormapping.htm cordialement
-- Jean-Yves BURLOT SI - EVEN Lait |
| |
| |
| | | |
|
| | |
| |
Posté le 08 octobre 2007 - 18:45 |
Bonjour...
Bien sur... ce n'est pas le cadre qui importe... C'est la complexité des traitements... La POO apporte un cadre de développement supplémentaire qui permet de structurer n'importe quel problème complexe d'une facon beaucoup plus générique...
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
andrianne jacky wrote:
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
|
| |
| |
| | | |
|
| | |
| |
Posté le 08 octobre 2007 - 19:10 |
Salut !
On 8-Oct-2007, "andrianne jacky" <j.andrianne@sam-bp.com> wrote:
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 !
-- Marcel Berman Président de Be-Dev (www.be-dev.be) Membre du conseil d'administration de Windasso Be-dev et Windasso sont des groupes d'utilisateurs de Windev, Webdev et Windev Mobile produits par la société PC-Soft (France) |
| |
| |
| | | |
|
| | |
| |
Posté le 08 octobre 2007 - 23:19 |
Bonjour Marcel...
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 ...
Disons que c'est maintenant plus facile... Mais même en windev 5.5, c'est quelque chose que je faisais déjà, avec des objets bien sur, et en transférant simplement le contenu du buffer fichier
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 ...
Oui... On se retrouve avec 3 'états' de l'enreg en mémoire... Origine, modifié, courant sur disque, et ca permet de gérer les modifs ou la synchro au niveau du champ...
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 !
Ayant utilisé cette méthode sur une appli de plus de 600 000 lignes de code, je la partage
En fait, plus on veut coder de manière générique (appli très personnalisables par les utilisateurs par exemple), plus la programmation object apporte des avantages
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html |
| |
| |
| | | |
|
| | |
| |
Posté le 08 octobre 2007 - 23:20 |
La POO a un intérêt dans tout code qui doit être utilisé plusieurs fois.
Elle apporte une souplesse, et une robustesse du code inégalées.
Elle peut convenir à la majorité des traitements (Interface, données etc...).
Le seul "Hic", c'est que programmer en POO demande une plus grande analyse du projet, et plus de rigueur.
On voit tout l'intérêt de la POO sur des projets où on a plusieurs 10aine de fenêtres.
Tous mes accès à la base passent par la POO. |
| |
| |
| | | |
|
| | | | |
| | |
|