Discussion :

[vilcoy]

Bonjour,

Je suis au stade de conception d'une nouvelle appli basée sur du MySQL et un frontal en VB .Net.
Je veux essayer d'appliquer au mieux les principes de la programmation objet, et j'ai l'impression que la meilleure solution est de faire "coller" mes classes aux tables de ma BDD.

Exemple :
SGBD :
une table personne, une table matériel
Une personne peut avoir 0 à n matériel.

Appli VB :
Une classe personne, une classe matériel
La classe "personne" a une propriété "matériels" qui est un tableau d'objets de type "matériel".

Dans le même ordre d'idée, je me pose une autre question :
Je compte mettre dans la classe personne des méthodes de type "insert", "update", qui vont contenir le code pour dialoguer avec le SGBD.
Dois-je mettre le même type de méthodes dans la classe "matériels" et les appeler depuis "personne" ou bien inclure tout le dialogue avec le SGBD dans la classe "personne" ?

Est-ce que je pars sur le bon chemin, ou bien suis-je en train de me planter ?

Quelles sont les bonnes pratiques ?

Merci pour vos conseils

[souviron34]

Juste un conseil :

En termes de conception, tu ne dois pas penser à avoir une structure identique dans la SGBD et l'interface.

Les buts sont différents, et donc éventuellement la structure également.

Si l'analyse des besoins utilisateurs et la conception de l'interface font que tu as des notions de personnes et de matériel, là tu peux te dire que côté IHM tu auras 2 types d'objets.

Conceptuellement, tu dois être capable de les demander à la BD. Mais sont-ils liés ?

De plus, dans la conception de la base, tout dépend du volume, de la fréquence de mise à jour, de beaucoup de choses...

Par exemple :

tu as 3 matériels
tu as 250 000 personnes..

tu as 3 personnes
tu as 25 matériels

Dans le 2ième cas, peut-être qu'un seul fichier "flat file" suffirait.

En résumé :

• Quelque soit la structure de la BD, ton application a besoin de 2 entités ou d'une (est-ce que matériel est une propriété de personne, ou est-ce que tu dois gérer une association entre les 2) ?
• Quelque soit l'IHM, quel est la méthode la plus appropriée pour le stockage et la récupération des paramètres ?

Cordialement

[vilcoy]

Merci pour tes conseils,

Je n'ai pas l'intention de prendre chaque table de ma base pour la transformer en classe, mais uniquement celles pour lesquelles il y a effectivement une correspondance logique.

Je prenais pour exemple des couples utilisateurs/matériels, mais en réalité mon application est une gestion de devis, pour laquelle l'utilisateur traitera :
- le devis dans son ensemble (classe/table devis)
- plusieurs lignes par devis (classe/table devisdetail)

Par rapport à tes commentaires, je pense que je suis dans le cas où le rapprochement table-classe est envisageable (au moins pour ces 2 types d'objet).
Reste le dialogue avec le SGBD que je ne sais pas trop comment gérer pour l'instant.

[souviron34]

juste pour commenter un peu sur le vocabulaire et la manière de penser :

Le fait d'utiliser des termes comme "classe" ou "table" est en soi (oui un truc "orienté objet"), mais surtout quelque chose d'attaché à une notion de programmation...

Donc je ne dis pas pour ce projet en particulier, mais de manière générale, lorque tu définis une spécification d'un produit, tu ne devrais référer en RIEN à une implémentation.

Une spécification système ou logicielle se fait en termes de langage naturel, compréhensibles par tous, et en particulier par l'utilisateur.

"table" renvoie à une base de données relationnelle. C'est de la technique. Et cela pré-suppose que l'on se servira d'une BDDR.

Dans la description d'une spécification, ce devrait être indiqué comme "BDD" ou "liste" ou "répertoire" ou "catalogue"

"classe" renvoie à la notion d'objet. Dans la description d'une spécification ce devrait être indiqué comme "entité", "ensemble de paramètres", "catégorie", "groupe", ...

Ce n'est que lors de la décision du ou des outils à utiliser, de la conception détaillée (et éventuellement préliminaire) que tu devrais préciser les termes comme "classe" ou "table".

Et encore, quand je dis préliminaire, ce n'est que dans quelques cas. De manière générale, pour les BDD, c'est plutôt du domaine de la conception détaillée (pseudo-code). Car jusqu'à ce stade-là, on est dans le concept de BDD. Et pour la réalisation, on pourrait chosiir une BDD objet, un fichier plat, une BDDR, ou autre chose...

Prenons ton exemple :

Spécification logicielle :

Donc dans ton cas, un devis (si nous avons la même définition ) est un "regroupement" d'évaluations de coûts de certaines fournitures.

Chaque fourniture comprend une description de l'objet de la fourniture, avec éventuellement un code interne, une quantité associée, un prix unitaire, éventuellement un indicateur pour savoir si il est disponible en stock, et éventuellement un indicateur pour savoir si il s'agit d'une évaluation (fourniture de prestation) ou d'un coût réel (fourniture matérielle).

Conception préliminaire :

Lorsque l'utilisateur établira un devis, il devra entrer soit le numéro de code soit la description (éventuellement partielle) des fournitures, de manière successive jusqu'à signification de la fin de la saisie.

La base devra contenir les informations nécessaires, c'est à dire :
- une liste des fournitures possibles
- éventuellement une liste d'abréviations correspondantes
- une liste correspondante des codes
- une liste correspondante de prix
- une liste correspondante de quantités en stock

Là, maintenant, tu peux faire une conception détaillée....

[FreshVic]

Bonjour,

Je suis assez d'accord avec Souviron34, en temps normal tu devrais faire une analyse, de l'analyse tu deduit des entité ou concept , tu detecte aussi des responssabilité des comportement , tu les associe ensuite a tes entité, ce qui te donne une classe et son comportement, ensuite parmis ces entité tu estimera qu'il faudra en faire persister certaines (dans une BDD relationnel ou XML ...).

Enfin bref revenons en au probleme , puisqu'il a deja ses table c'est que le boulot d'analyse est deja plus ou moins fait, tu peux effectivement partir du principe une classe par table ce n'est pas une regle pour toutes les base et appli mais a priori dans ton cas c'est pas choquant.

Ces classes sont des objet dit metier, elles ont les données et le comportement associé a ces données.
En fait ce qui me gene dans ce qui a été dit , c'est qu'a priori selon vous il n'y a que 2 couches , la BDD et l'IHM, ce qui est une grave erreur, si tu fais ca tu va avoir dans l'ihm tous les traitement metier alors que le role de l'ihm n'est que d'afficher le resultat du metier.

Autre chose tres tres tres genante (selon moi) , ce sont les methodes insert, update et delete que tu souhaite mettre dans tes objets, l'un des principe de base de l'objet est le SRP (Single Responssability principle) une classe ne doit avoir qu'une seul responssabilité et donc avoir le moins possible de raisons de changer.
Et si tu donne la responssabilité de se charger de la persistance en plus de son role metier , tu va a l'encontre de ce principe, pour les acces base tu doit avoir une couche supplémentaire qui est le DAO (Data Access Object).

Tu peux regarder du coté de http://www.application-servers.com/a.../multicouches/ je ne suis pas d'accord avec tout ce qu'ils disent mais ca plante deja le decor.

[jpelaho]

Je passe sur les notions de classe et tables qui ont été plus ou moins été expliqués plus haut. J'éviterai aussi le débat sur le nombre de couches à ajouter ou à diminuer dans une application ...

Quand on voit tes deux classe Personne et Matériel. La relation entre les deux est une agrégation au sens UML. C'est-à-dire une relation de type ensemble/éléments. J’irai même plus loin en disant qu’il s’agit d’une composition (agrégation forte) parce que je suppose qu’un matériel n’appartient à un moment donné qu’à une seule personne et que toute mise à jour sur une personne entraîne la mise à jour de ses matériels.

Ceci me fait penser qu’il serait « logique » de mettre les fonctions de mise à jour des matériels dans la classe Personne. Tu ne pourrais avoir des fonctions InsertMateriel, UpdateMateriel et DeleteMatériel dans la classe Personne.