Discussion :

[xanav]

Bonjour,

Je suis actuellement en cours de développement de ma 1ère vraie application C#. Pour l'instant, j'ai créé ma base et construit mon modèle grâce à Entity en utilisant la méthode Database first.
Je suis face à un problème pour lequel je n'arrive pas à trouver une solution "propre" :
Dans ma base, j'ai une table qui référence des volailles (T_SUBJECT) et 2 tables pour gérer les baguages (et pas bagage ! attention, ça rien à voir ) : 1 une pour les bagues courantes (T_BANDING) et une pour l'historique des baguages (T_BANDING_HISTORY). J'avais lu (sur développez.com) que cette méthode était la meilleure façon de gérer ce genre de données, permettant d'avoir notamment une contrainte d'unicité en base sur les numéros de baguages courants, sans avoir cette contrainte sur l'historique.
Mais pour mes classes métier, ça ne me semble pas logique d'avoir 2 classes différentes pour les baguages courants et les baguages historisés. Ce qui me semblerait le mieux serais de n'avoir qu'une classe "Banding" avec une propriété date début et date de fin, cette deuxième restant nulle pour les baguages courants. La classe "Subject" aurait 2 propriétés, une pour la (ou les) bague(s) que possède actuellement la volaille et une pour son historique, toutes 2 de type List<Banding>.
Le problème c'est qu'Entity ne permet pas (ou alors je n'ai pas trouvé comment) de faire ce genre de choses. Les seuls cas d'une entité pour 2 tables que j'ai trouvé concerne le stockage de certaines propriétés dans une table et certaines dans une autre. Moi ce que je voudrais, ce serait écrire dans l'une ou l'autre des tables suivant les cas.

Ce cas me semble assez commun, on retrouve régulièrement le même genre de choses avec les connexions d'un utilisateur et son historique de connexion.
Alors quel est la meilleure manière de faire ? Est-ce la construction de ma base qui est à revoir ? mon modèle ? ou carrément oublier Entity ?

Merci d'avance.

[myNameIsFlo]

Si je comprends bien...
T_BANDING a une clé étrangère dans T_BANDING_HISTORY. Tu as 2 tables dans sql, 2 entités (classe) avec entity.

Quoiqu'il arrive. Libre à toi d'encapsuler le comportement des 2 classes dans une seule.
Sinon Entity est une couche d’accès aux données qui respectera le model relationnel que tu as mis en place. Je ne vois pas en quoi tu dois remettre en question tes choix de techno qui n'ont rien à voir avec la question relative au modèle relationnel.

[xanav]

Non, en fait, il n'y a pas de lien entre T_BANDING et T_BANDING_HISTORY si ce n'est qu'elles ont toutes les 2 une clé étrangère qui pointe T_SUBJECT. Concrètement, lorsqu'on retire la bague de l'animal, on supprime l'enregistrement de T_BANDING et on insère son équivalent (numéro de bague + Date début) dans T_BANDING_HISTORY avec une date de fin (enfin c'est le fonctionnement que j'avais prévu.

Libre à toi d'encapsuler le comportement des 2 classes dans une seule.

Donc, pour toi, il faudrait que je laisse les 2 classes dans Entity et que je créé une nouvelle classe qui utiliserait les 2 classes Banding et BandingHistory, écrivant avec l'une ou l'autre suivant les cas ? Et cette nouvelle classe serait une classe métier dont le modèle Entity n'aurait pas connaissance ?
Je ne sais pas si j'ai bien compris, mais ça me semble une bonne idée. En fait c'est con mais je n'avais pas penser à faire d'autres classes métier en dehors du modèle Entity.