Discussion :

[babedt]

Bonjour,
je vais faire un objet "Client". Cet objet aura une méthode .Add afin de permettre l'ajout d'un client dans un base de données.
Cet objet aura d'autres méthodes et un ensemble de propriétés qui correspondent + ou - aux différentes colonnes de ma table CLIENT.
Question: comment passer les informations à mon objet Client pour appliquer la méthode .Add ?

Methode 1 : utiliser les propriétés de l'objet Client dnas la méthode Add
Client = new Client();
Client.numero = 123;
Client.nom = "eee";
Client.adresse = "aaa";
Client.Add();


Methode 2 : Passer toutes les info en paramétres de la méthode .Add
Client = new Client();
Client.Add (numero, nom, adresse);
// ou numero, nom, adresse sont des variables


Methode 3:Créer une structure qui sera passée en paramétre à la méthode .Add
StructAddClient structAddClient = new StructAddClient
structAddClient.numero = 123;
structAddClient.nom = "eee";
structAddClient.adresse= "aaaa";
Client = new Client();
Client.Add (structAddClient);

Pour ma part, j'ai une préférence pour la 3eme méthode car elle permet à l'utilisateur de l'objet de connaître précisément les champs à initialiser.

Qu'elle est la mieux, y en a t il d'autres ?

[TheCaribouX]

je ne sais pas dans quel language tu programme (peut etre que tu l'as précisé mais j'ai pas du le lire), mais pourquoi ne pas faire un constructeur de ta classe client avec tes trois champs n°, adresse et nom. Ensuite ta méthode Add ajouterait ton objet client, bêtement, dont les membres sont ceux spécifiés ?

Si tu fais de la POO, c'est ce qui me paraitrait le plus intuitif, mais je suis pas non plus LA référence en programmation...

[_vince_]

Bonjour,
je vais faire un objet "Client". Cet objet aura une méthode .Add afin de permettre l'ajout d'un client dans un base de données.
Cet objet aura d'autres méthodes et un ensemble de propriétés qui correspondent + ou - aux différentes colonnes de ma table CLIENT.
Question: comment passer les informations à mon objet Client pour appliquer la méthode .Add ?

Methode 1 : utiliser les propriétés de l'objet Client dnas la méthode Add
Client = new Client();
Client.numero = 123;
Client.nom = "eee";
Client.adresse = "aaa";
Client.Add();


Methode 2 : Passer toutes les info en paramétres de la méthode .Add
Client = new Client();
Client.Add (numero, nom, adresse);
// ou numero, nom, adresse sont des variables


Methode 3:Créer une structure qui sera passée en paramétre à la méthode .Add
StructAddClient structAddClient = new StructAddClient
structAddClient.numero = 123;
structAddClient.nom = "eee";
structAddClient.adresse= "aaaa";
Client = new Client();
Client.Add (structAddClient);

Pour ma part, j'ai une préférence pour la 3eme méthode car elle permet à l'utilisateur de l'objet de connaître précisément les champs à initialiser.

Qu'elle est la mieux, y en a t il d'autres ?

Methode 4:
martin = new Client(numero, nom, adresse);
dbTruc.addClient(martin)

Tu crees un client independamment de n'importe quelle base de donnees. Tu ajoutes un client grace a une classe qui gere l'insertion, la suppression des donnees dans ta BDD. C'est plus simple si tu veux changer de BDD. Tu peux meme avoir une classe par BDD.

La methode 1 n'est pas OO. Et la methode 3 est trop compliquee. Un constructeur avec 3 variables, c'est facile a initialiser.

[TheCaribouX]

au moins on est d'accord

[babedt]

même si ma table possède plus de 30 colonnes (donc 30 param pour mon constructeur). J'en ai mis que trois dans les exemples pour ne pas avoir un trop gros poste...

Je développe en C# (je ne l'avais pas précisé)

[slim]

je pense... oui. Meme si ta table possède plus de 30 colonnes. Dans tous les cas, si ce sont les temps de réponse auxquels tu pense, la "méthode 4" est optimale...

[koala01]

Salut,

*Peut-être* devrais tu déjà réfléchir à l'éventualité de "subdiviser" cette table composé d'énormément de champs en plusieurs tables en contenant chacune beaucoup moins.

En effet, même si je ne remet absolument pas en question le fait qu'un "client" puisse véhiculer une trentaine d'informations différentes, il faudrait déjà voir le nombre d'informations qui ne sont pas utilisées d'office (soit parce que l'utilisation d'une information donnée "empêche" celle d'une autre, soit parce qu'une information particulière est facultative dans certaines conditions)...

Entendons nous bien: ne sachant absolument pas quels objectifs sont poursuivis par la base de données, je ne me permettrai pas de juger de la nécessité de disposer de ces trente champs.

Par contre, je me pose des questions sur l'utilité de voir apparaitre ces trente champs dans une seule et même table...

Il faut savoir que, si ta table est composée de trente champs et que seule une dizaine sont effectivement utilisés en permanence, alors que les autres sont d'utilisation facultative, cela fini quand même par représenter une dépense d'espace inutile impressionnante.

Le tout sans compter que les requêtes de sélection et de mise à jour sont rendues bien plus difficile sur ce genre de table.

Evidemment, si tu n'es pas libre de la manière d'envisager les tables de la base de données, je comprendrai si tu me dis que tu ne peux pas la changer

D'un autre coté, on dit souvent qu'en OO, si un objet a plus d'une responsabilité, c'est sans doute qu'il en a trop...

Je t'inviterais donc aussi à réfléchir aux responsabilités qui reviennent clairement à ton "client" et à celles qui devraient échoir à d'autres objets

De manière générale, il me semble de bon ton de se dire que, quitte à fournir une référence sur le "client" en cours de gestion, il me semblerait cohérent de distribuer différemment les responsabilités (tant du point de vue de la BDD que du point de vue des différentes classes que tu envisage de créer )

[babedt]

Merci pour toutes ces réponses (qui vont dans le même sens) :

Pour la petite histoire : j'ai évoqué une table CLIENT pour l'exemple - plus simple pour en discuter.
En fait, je travaille dans le milieu industriel et je dois gérer beaucoup d'informations. La table en question a déjà été "explosée" en trois tables (avec des relations 1,1 de chaque côté) - ce sont + ou - des données de fabrication de produits.

Merci encore