Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2818 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  EJB et persistance des données : bonnes pratiques

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

EJB et persistance des données : bonnes pratiques

n°2046730
jhnattal
Kiwi pour les intimes
Posté le 06-01-2011 à 10:27:42  profilanswer
 

Bonjour à tous,
 
Dans le cadre d'un projet universitaire, je développe actuellement une application tournant sur un serveur Glassfish.
 
Une question de bonnes pratiques me vient à l'esprit :
 
Lors de la persistance de données, faut-il privilégier la persistance via les listes en cascade ou via une méthode appropriée ?
 
Exemple :
 
Une personne possède une ou plusieurs adresses.
 

Code :
  1. Addresse uneAdresse = new Adresse();
  2. uneAdresse.setLibelle("blablabla" );
  3. // etc...
  4. // 1ère possibilité
  5. laPersonne.getAdresses().add(uneAdresse);
  6. remoteInterface.savePersonne(laPersonne); // Sauvegarde de la personne et des adresses en cascade
  7. // 2ème possibilité
  8. remoteInterface.saveAdresse(uneAdresse); // Sauvegarde de l'adresse uniquement


 
Quelle est la meilleure pratique ?  
 
Sachant que la 1ère solution m'évite de créer la méthode saveAdresse....
 
Merci d'avance :)

mood
Publicité
Posté le 06-01-2011 à 10:27:42  profilanswer
 

n°2047399
Ju -
Posté le 07-01-2011 à 16:48:40  profilanswer
 

Salut,
Je pense que les deux solutions sont possibles.
Cependant, l'une sera plus adaptée que l'autre selon la fréquence des transactions et le volume des arguments.
Ex: si une personne entre 5 adresses, et sauve dans l'appli:
- Solution 1: 1 transaction atomique est nécessaire
- Solution 2: 5 transactions atomiques sont nécessaires
 
La solution 2 sera dans ce cas la moins performante car nécessitera l'établissement de la connexion, la localisation de la procédure distante, l'appel distant, la fermeture de connexion et tout ça 5 fois.
 
Donc la solution 1 serait plus performante, puisque réalisable en un seul appel. Sauf que si une valeur Personne possède 1000 adresses et que le réseau est lent, 1 seule transaction pour l'écrire en base signifiera une transaction beaucoup plus longue.
 
Donc la solution 1 privilégie la sécurité et l'intégrité des données écrites (commit effectué quand l'objet Personne entier a été écrit), la solution 2 privilégie une continuité de service maximale (commit effectué à chaque adresse écrite).

n°2047411
jhnattal
Kiwi pour les intimes
Posté le 07-01-2011 à 17:08:28  profilanswer
 

Merci pour tes éclaircissements,
 
J'ai finalement opté pour la 2ème solution afin que chaque bean garde une certaine indépendance :
 
le fait de devoir appeler l'objet Personne pour sauvegarder une Adresse est finalement assez contraignant (et mes assertions se chargent de vérifier l'intégrité des données dans la fonction save).
 
Par rapport à ton exemple, le projet est une boutique en ligne, je voulais appliquer la 1ère solution à des Produits qui appartiennent à une Catégorie.
 
Si je souhaitait sauvegarder un Produit en cascade via une Catégorie, cela va me sauvegarderait les milliers de produits que contiendrait la catégorie pour finalement un seul produit.
 
Merci encore :)


Message édité par jhnattal le 07-01-2011 à 17:09:03

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  EJB et persistance des données : bonnes pratiques

 

Sujets relatifs
Convertir un tableau en liste de données VBA sous Exceltraitement un fichier de données en C++
[RM COBOL 7.5 & SQLSVR] Injection données COBOL dans SQL Server Comment récupérer et afficher les données d'un formulaire html
envoi de données de form vers 2 fichiers phpActualiser une liste de données tirées d'une table Mysql en PHP
Les EJBRécupération de données XML dans des tableaux
[MySQL] Ajouter une colonne et les données d'une autre tableCouplage faible/fort, RM, WS, EJB ...
Plus de sujets relatifs à : EJB et persistance des données : bonnes pratiques


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR