2010-05-20 3 views
5

J'ai une question qui est plus dans le domaine de la conception, que de l'implémentation. Je suis également heureux pour quiconque de signaler des ressources pour la réponse et je serai heureux, de recherche pour moi-même.Bonne conception de mappage des objets de domaine Java aux tables (en utilisant Hibernate)

Java et SQL très simplifié:

Dire que j'ai un domaine d'affaires POJO appelé « Image » avec trois attributs.

class Picture 
    int idPicture 
    String fileName 
    long size 

Dire que j'ai un autre domaine d'affaires POJO appelé "Item" avec 3 attributs

class Item 
    int idItem 
    String itemName 
    ArrayList<Picture> itemPictures 

Ce serait une relation simple normale. Vous pourriez dire que l'objet 'Picture', n'existera jamais en dehors d'un objet 'Item'. On suppose une image appartient uniquement à un élément spécifique, mais qu'un élément peut avoir plusieurs images

maintenant - en utilisant une bonne conception de base de données (3ème forme normale), nous savons que nous devons mettre des articles et images dans leurs propres tables. Voici ce que je suppose serait correct.

table Item 
    int idItem (primary key) 
    String itemName 

table Picture 
    int idPicture (primary key) 
    varchar(45) fileName 
    long size 
    int idItem (foreign key) 

Voici ma question: Si vous effectuez des fichiers de mapping Hibernate pour ces objets. Dans la conception de données, votre table d'images a besoin d'une colonne pour faire référence à l'élément, de sorte qu'une relation de clé étrangère peut être maintenue . Toutefois, dans vos objets de domaine d'entreprise - votre objet Image ne contient pas de référence/d'attribut à l'idItem de Item - et n'a pas besoin de le savoir. Une instance d'image Java est toujours instanciée dans une instance d'élément. Si vous voulez connaître l'objet auquel l'image appartient à vous êtes déjà dans la bonne portée. Appelez myItem.getIdItem() et myItem.getItemPictures(), et vous avez les deux informations dont vous avez besoin.

Je sais que les outils Hibernate ont un générateur qui peut automatiquement rendre vos POJO de regarder à votre base de données. Mon problème vient du fait que j'ai planifié d'abord la conception des données pour cette expérience/projet . Puis quand je suis allé faire les objets java de domaine, je me suis rendu compte que une bonne conception a dicté que les objets contiennent d'autres objets d'une manière imbriquée. Ceci est évidemment différent de la façon dont un schéma de base de données est - où tous les objets (tables) sont plats et ne contiennent aucun autre type complexe en leur sein. Quel est un bon moyen de concilier cela?

-vous:

(A) Effectuez les fichiers de mappage de mise en veille prolongée afin que Picture.hbm.xml a une cartographie à la idItem des parents POJO terrain (s'il est même possible)

(B) Ajouter un attribut int dans la classe Picture pour faire référence à l'idItem et le définir à l'instanciation, simplifiant ainsi le fichier de mappage hbm.xml en ayant tous les champs de table comme attributs locaux dans la classe

(C) Corrigez la conception de la base de données car elle est faux, dork.

Je serais vraiment apprécier tous les commentaires

+0

@M. McKenzie, voulez-vous nous donner des commentaires sur nos réponses? –

Répondre

3

Il me semble que vous n'avez pas vraiment besoin de quelque chose dans Picture pour référencer son Item, comme vous avez dit que vous aurez toujours la Item lorsque vous avez la Picture.

Mais s'il s'avère que vous avez vraiment besoin de cette référence, alors c'est le cas de la configuration de l'association unidirectionnelle un-à-plusieurs.

Voyez comment cela se fait ici:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/collections.html

Exemple:

<class name="Item"> 
    <id name="id" column="item_id"/> 
    .... 
    <set name="pictures" inverse="true"> 
     <key column="item_id"/> 
     <one-to-many class="Picture"/> 
    </set> 
</class> 

<class name="Picture"> 
    <id name="id" column="picture_id"/> 
    .... 
    <many-to-one name="item" 
     class="Item" 
     column="item_id" 
     not-null="true"/> 
</class> 
+0

Merci beaucoup, excuses pour la réponse tardive. J'ai emprunté le livre de Gavin King à un ami et parcouru les chapitres sur les collections qui éclaircissaient beaucoup ce concept. –

0

Votre table d'image devrait être modifié pour tenir une référence à la table d'éléments, vous pouvez stocker plusieurs images d'articles. En ce qui concerne le mappage d'hibernation, vous pouvez mapper une collection d'objets dépendants (images) dans le fichier hbm de l'objet principal (Item). C'est ce qu'on appelle la cartographie des composants.

Vous pouvez consulter le guide de mise en veille prolongée:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/components.html#components-incollections

+0

Vous pouvez consulter le guide d'hibernation: http://docs.jboss.org/hibernate/core/3.3/reference/fr/html/components.html#components-incollections – Gala101

0

Je ne suis pas sûr de la configuration xml derrière, mais en utilisant les annotations que vous pouvez juste faire quelque chose comme ça (JPA 2.0):


@Embeddable 
class Picture 
    int id 
    String filename 
    long size 

class Item 
    int idItem 
    String itemName 

    @ElementCollection 
    @CollectionTable(name = "item_picture", joinColumns = @JoinColumn(name = "item_id")) 
    List<Picture> pictures 
+0

Ceci est très intéressant et simple! J'avais seulement l'intention d'utiliser l'implémentation d'Hibernate et de rechercher ses capacités d'annotation plus tard - mais cela m'intéresse maintenant. Merci beaucoup! –

0

Y a-t-il d'autres attributs de l'association? Tels que les dates, statuts, etc? Si oui, je le modeler comme:

table Item 
    int idItem (primary key) 
    String itemName 

table Picture 
    int idPicture (primary key) 
    varchar(45) fileName 
    long size 

table ItemPictureAssociation 
    int idItem (foreign key) 
    int idPicture (foreign key) 
    int sequence (composite PK) 
    <other columns> 

De cette façon, vous pouvez maintenir un à plusieurs, garder les deux objets propres détails séparés, et maintenir les attributs de la relation le cas échéant.

Questions connexes