2 votes

Quelle est la meilleure façon de relier les tables des bases de données relationnelles aux classes Java ?

Je me demande si quelqu'un peut me conseiller ; j'ai une application qui comporte des classes de ce type :

Code :

public class Order implements Serializable { 
    private int orderNo; 
    private int customerNo;    
    private date orderDate; 

    public int getOrderNo () { 
        return orderNo; 
    } 

    public int getCustomerNo () { 
        return customerNo; 
    } 

    public date getOrderDate () { 
        return orderDate; 
    } 

    // And so on with set methods. 

} 

public class OrderLine implements Serializable { 
    private int orderNo; 
    private int lineNo;    
    private int qty; 
    private int prodID; 

    // Get and set methods for each of the above. 
    public int getOrderNo () { 
        return orderNo; 
    } 

    public int getLineNo () { 
        return lineNo; 
    } 

    public int getQty () { 
        return qty; 
    } 

    public int prodID () { 
        return prodID; 
    } 
    // And so on with set methods. 
}

Cela se traduit directement par une table relationnelle :

Ordre : orderno, customerNo, orderDate OrderLine : orderno, lineNo, qty, prodID

Ainsi, chaque classe se traduit directement par une table de base de données avec des paires "get" et "set" pour chaque attribut.

Ce que j'aimerais savoir, c'est si dans une application web Java, les classes doivent être telles qu'elles sont ci-dessus ou plutôt comme ceci où les gets renvoient des objets :

Code :

public class Order implements Serializable { 
    private int orderNo; 
    private Customer;    
    private date orderDate; 
    private ArrayList<OrderLine>lineItems; 

    public int getOrderNo () { 
        return orderNo; 
    } 

    public Customer getCustomer () { 
        return Customer; 
    } 

    public date getOrderDate () { 
        return orderDate; 
    } 

    public ArrayList<OrderLine> getOrderLines () { 
        return lineItems; 
    } 

    public OrderLine[] getOrderLines () { 
        return lineItems; 
    } 
    // And so on with set methods.     
} 

public class OrderLine implements Serializable { 
    private int orderNo; 
    private int lineNo;    
    private int qty; 
    private Product; 

    // Get and set methods for each of the above. 

    public int getOrderNo () { 
        return orderNo; 
    } 

    public int getLineNo () { 
        return lineNo; 
    } 

    public int getQty () { 
        return qty; 
    } 

    public int getProduct () { 
        return Product; 
    } 
}

Quelle est la meilleure approche ? Ou bien l'une ou l'autre approche importe-t-elle vraiment tant que les classes qui traitent les données le font correctement et que le système fonctionne efficacement ?

Remerciements

M. Morgan

2voto

Michael Borgwardt Points 181658

Il n'y a absolument aucune raison d'utiliser la première forme - il sera beaucoup plus difficile de travailler avec le code Java, et il y aura beaucoup de bogues qui en résulteront.

Tous les mappeurs O/R décents (Hibernate étant le plus populaire) traduiront le schéma de la base de données en graphes d'objets OO appropriés sans aucun problème.

Cependant, l'inconvénient est que le fait de faire tout cela à votre place peut avoir pour conséquence très mauvaise performance lorsque vous confiez tout au mappeur OR et qu'il récupère trop ou trop peu de données de la base de données, vous devez donc prêter attention à la mise en cache et au fait que vos collections sont Chargement paresseux ou impatient .

1voto

Andrew Corkery Points 804

Si vos objets commerciaux sont aussi propres que cela, je suggérerais peut-être d'envisager un mappeur ORM tel que Hibernate ou ActiveObjects.

Si vous préférez construire votre propre couche d'accès aux données, je vous suggère de rendre ces classes aussi légères que possible. Par exemple, dans Order J'aurais une CustomerID champ entier qui représenterait la clé étrangère, au lieu d'avoir un champ de type getCustomer() renvoyant un Customer dans l'objet Order la classe affaires.

Les méthodes de récupération telles que getCustomer() serait probablement mieux placé dans une classe différente telle que CustomerDAO etc. qui contient votre fonctionnalité d'accès aux données.

Du point de vue de l'efficacité, l'approche choisie n'a pas vraiment d'importance, mais il est toujours bon d'avoir des objets faiblement couplés.

1voto

A_M Points 2897

Vous devriez examiner un outil de mappage objet-relationnel (ORM), tel que Hibernar o TopLink ou peut-être un outil de mappage de requêtes plus simple comme iBatis .

Je pense que vous obtiendrez quelque chose qui ressemble davantage à votre deuxième suggestion si vous suivez la voie de l'ORM.

1voto

David Rabinowitz Points 14133

La façon la plus courante de le faire est d'utiliser une bibliothèque de mappage objet-relationnel (ORM). Les plus courantes sont les suivantes :

Toutes ces bibliothèques sont open source et mettent en œuvre la norme JPA (Java Persistence Architecture).

1voto

Jim Ferrans Points 13673

Je vous encourage également à examiner un outil de mappage objet-relationnel comme Hibernate, ou un outil de mappage SQL plus simple comme iBatis. (J'ai eu une très bonne expérience avec iBatis).

En ce qui concerne la modélisation de la relation maître-détail entre une commande et ses lignes de commande, au niveau de l'objet Java, elles font certainement partie de la même hiérarchie conceptuelle, et je choisirais donc de les modéliser comme un objet Commande qui contient une liste. De cette façon, je pourrais faire circuler des commandes complètes dans mon code sans jamais craindre d'en perdre des parties.

Si vous utilisez un mappeur SQL comme iBatis, vous devez créer une table Order et une table OrderLine dans votre base de données, et donner à iBatis une carte XML qui lui indique comment assembler votre hiérarchie d'objets composés Java Order/OrderLine en joignant les deux tables SQL. Les ORM fonctionnent à l'inverse, en générant les tables SQL sur la base de votre modèle de données Java.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X