Objet dans Objet instancié via BDD

Bonjour à mes lecteurs :ccool:

J'ai du mal a formuler ma demande, car j'ai l'impression que c'est un truc banal, mais j'parviens pas a trouver les termes "officiels" pour en parler :aie:


J'ai 2 classes : Livre et Editeur.

Code:

---

1 2 3 4 5 6 7 8 9 10

class Livre { private int idLivre; private string titreLivre; private Editeur editeur;   public Livre() { } }

---

Code:

---

1 2 3 4 5 6 7 8 9

class Editeur { private int idEditeur; private string nomEditeur;   public Editeur() { } }

---

Mes questions sont :

- comment fonctionnerait le constructeur du Livre, puisqu'il doit egalement instancier l'editeur.

- mon appli est reliée à une bdd. Donc lorsque je fais une lecture d'un livre déja existant (mon ecran de consultation), il faudrait que mon constructeur lise la bdd tout en instanciant l'editeur grace à son id trouvé dans la table Livre de ma bdd.

- dans le cas d'un nouveau livre, j'récupère l'idEditeur dans l'écran de saisie, et j'dois donc instancier un livre sans identifiant, mais avec son titre et son editeur, lui meme instancié grace a son id, permettant de recuperer son nom dans la bdd.



Je pense qu'avec la 1 et la 2, la 3 devrait se déduire, mais j'avoue que pour le moment je bloque totalement, et j'ai peur de faire du code ultra crade...

Donc j'me dis que quitte a apprendre, autant apprendre du code propre :ccool:

Pour ton petit 1, tu peux juste faite une propriété éditeur :

Code:

---

public Editeur EditeurLivre {get; set;}

---

Ensuite, tu instancies tes objets :

Code:

---

1 2 3 4 5 6 7

Editeur monEditeur = new Editeur(); monEditeur.Nom = "SuperEditeur";   Livre monLivre = new Livre(); monLivre.Titre = "SuperTitre"; monLivre.Editeur = monEditeur;

---

Je pense que le reste tu le déduiras de toi même ;p

Merci, mais je voulais surtout savoir s'il fallait faire des constructeurs spécifiques.

notamment du fait que je vais beaucouop travailler a partir de ma bdd.


A moins que le plus propre soit d'instancier a vide, puis ensuite de "setter" 1 a 1 les valeurs récupérées dans la bdd?


en tout cas, pour l'editeur j'pensais pas que ce serait si "simple" ^^

Par contre, c'est a mettre dans le ctor du Livre, ou dans mon code de mes winform, avant l'instanciation du livre?

En fait, la "magie" de la POO apparait principalement quand on sépare les responsabilité. Ta classe Livre sert a stocker des informations : Un titre, un éditeur, etc ... C'est donc une structure de données.

Elle ne doit donc pas instancier d'objet car ce n'est pas son rôle. Tes instanciations doivent se faire soit via une Factory (Un Design Pattern qui est peut être un peu compliqué a ton niveau) soit dans le code de ta couche la plus haute (UI/main/etc).

De mémoire, pour les objets servant à faire un lien avec la base de données, la bonne pratique est de les instancier via le constructeur par défaut (sans paramètres) et d'ajouter les champs comme dans l'exemple que je t'ai mis !

ok merci !


Donc en fait c'est un peu ce que je faisais déja en asp.net, mais comme j'ai appris sur le tas, j'pensais que ce que je faisais était pas clean.

C'etait surtout le cas d'une classe en integrant d'autres qui me bloquait.

Merci beaucoup ;) (et oui j'confirme, les design patern, déjà entendu parlé, et déjà fui!! :mouarf: )


Topic résolu

Citation:

---

Envoyé par MaximePalmisano

De mémoire, pour les objets servant à faire un lien avec la base de données, la bonne pratique est de les instancier via le constructeur par défaut (sans paramètres) et d'ajouter les champs comme dans l'exemple que je t'ai mis !

---

Je ne suis pas tout à fait d'accord avec les réponses.
Un constructeur prends les paramètres dont l'objet à TOUJOURS BESOIN. Pose-toi la question "est-ce que, pour chaque instance de Livre, je dois avoir une instance de l'éditeur ?" Si la réponse est oui, alors tu peux mettre dans le contructeur de Livre La création de l'Editeur.
Cependant il n'est pas normal de donner au constructeur de Livre les paramètres de l'éditeur. Pour bien faire, il faut d'abbord contruire l'Editeur et passer ce dernier en paramètre du constructeur de Livre.
Ensuite, tu as effectivement le patron Factory pour valuer tes objets.
Tu peux également concevoir une DAL avec, dans chaque classe, une méthode :

Code:

---

private MaClasse Fill(DataReader dr)

---

ce qui te permet de Factoriser toutes les façons de créer tes objets...
Imagine que ta classe propose GetBookByTitle, GetBookById, etc. Toutes ces méthodes font appel au même Fill pour retourner un objet Livre

Je me suis peut être mal exprimé mais c'est ce que je voulais dire. Il peut soit passer son éditeur par injection, soit remplir le champ après mais dans tous les cas, il ne doit pas laisser son Livre les construire.

Pour en revenir au constructeur par défaut, je me base sur ce que Microsoft demande pour les POCOs utilisés avec EF :

Citation:

---

Une classe de données personnalisée doit avoir un constructeur public ou protected qui n'a pas de paramètres.

---

http://msdn.microsoft.com/fr-fr/library/dd468057.aspx

Il est possible que je sois à côté de la plaque mais une explication du pourquoi serait la bienvenue :)

De la même manière que la classe de désérialisation xml utilise un contructeur sans paramètre.
C'est un constructeur qui est toujours là (sauf si tu défini un autre paramètre sans redéfinir celui là) donc on s'appuie dessus.
Après le constructeur prend les paramètres COMMUNS A TOUTES LES INSTANCES. Je veux dire qui sont nécessaires dans tous les cas.
Par exemple tous les livres ont un titre, donc le titre est un paramètre de constructeur. Tu vois l'idée ?