Séparer la couche d'accès aux données : TransfertObject

Séparer la couche d'accès aux données : TransfertObject - Java - Programmation

Marsh Posté le 01-05-2007 à 15:07:58    

Salut,  
 
dans mon application j'ai voulu séparer la couche d'accès aux données de la couche métier (étonnant non ?!). Et je tombe là dessus : http://java.sun.com/blueprints/cor [...] bject.html
 
Ma question porte sur le TransfertObject. Mon application respecte le schéma décrit dans la page mise en lien (DAO, abstract factory, ...), sauf pour le TransfertObject. En effet, je trouvais ça extrêment redondant d'avoir un TransfertObject qui aurait quasiment les mêmes attributs que l'objet de la couche métier qui serait instancié en l'utilisant.
 
A la place, ma couche d'accès aux données retourne un HashMap<String, Object> où String peut être le nom du champ dans la base, ou un nom de remplacement si on veut, et Object est la valeur de ce champ. C'est ensuite les loaders de la couche métier qui cast cet Object dans le type attendu.
 
Est-ce que ça tient la route ? C'est crado ? Vous faîtes comment vous ?

Reply

Marsh Posté le 01-05-2007 à 15:07:58   

Reply

Marsh Posté le 01-05-2007 à 19:45:29    

c'est ce que l'on appele des beans , des objets métiers mappant bien souvant une table de la base, par exemple une commande, une ligne de commande, une facture , un utilisateur , etc...
 
Donc oui c'est plus propre que le cast que tu utilises mais non ce n'est pas obligatoire, c'est juste des bonnes pratiques....
 
Perso , moi c'est la méthode que j'emploi au boulot et pour mes devs persos, je prefere...

Reply

Marsh Posté le 02-05-2007 à 13:02:43    

Donc si j'ai une classe de la couche métier genre Customer :  

Code :
  1. public class Customer
  2. {
  3.     public String firstName;
  4.     public String lastName;
  5.     public int customerId;
  6.     ...
  7. }


 
il faut que je mette en place un bean comme ça ?

Code :
  1. public class CustomerBeans
  2. {
  3.     public String firstName;
  4.     public String lastName;
  5.     public int customerId;
  6.     ...
  7. }


 
C'est bien ça ou j'ai mal compris ? Parce que c'est ultra redondant quand même ^^

Reply

Marsh Posté le 02-05-2007 à 19:25:41    

Ah non si tu as déja ta classe Customer c'est bon,  
par contre la haspmap dont tu as parlé dans ton premier message la c'est moins bien ;)

Reply

Marsh Posté le 03-05-2007 à 12:52:05    

Hmm pourtant, je pensais que les DAO n'avaient pas à connaître la couche métier, ils ne peuvent donc pas utiliser la classe Customer non ?
 
Et quand je regarde sur la page sun ( http://java.sun.com/blueprints/cor [...] bject.html ), le TransfertObject ressemble fortement à une classe reprenant les attributs de la classe de la couche métier. Je copie colle leur exemple de code :  
 
Example 8.3 Implementing the Transfer Object Pattern - Transfer Object Class

Code :
  1. // Transfer Object to hold the details for Project
  2. public class ProjectTO implements java.io.Serializable {
  3.     public String projectId;
  4.     public String projectName;
  5.     public String managerId;
  6.     public String customerId;
  7.     public Date startDate;
  8.     public Date endDate;
  9.     public boolean started;
  10.     public boolean completed;
  11.     public boolean accepted;
  12.     public Date acceptedDate;
  13.     public String projectDescription;
  14.     public String projectStatus;
  16.     // Transfer Object constructors...
  17. }


 
 
Example 8.4 Implementing the Transfer Object Pattern - Entity Bean Class

Code :
  1. public class ProjectEntity implements EntityBean {
  2.     private EntityContext context;
  3.     public String projectId;
  4.     public String projectName;
  5.     public String managerId;
  6.     public String customerId;
  7.     public Date startDate;
  8.     public Date endDate;
  9.     public boolean started;
  10.     public boolean completed;
  11.     public boolean accepted;
  12.     public Date acceptedDate;
  13.     public String projectDescription;
  14.     public String projectStatus;
  15.     private boolean closed;
  17.     // other attributes...
  18.     private ArrayList commitments;
  19.     ...
  21.     // Method to get Transfer Object for Project data
  22.     public ProjectTO getProjectData() {
  23.       return createProjectTO();
  24.     }
  26.     // method to create a new Transfer Object and  
  27.     // copy data from entity bean into the value  
  28.     // object
  29.     private ProjectTO createProjectTO() {
  30.         ProjectTO proj = new ProjectTO();
  31.         proj.projectId = projectId;
  32.         proj.projectName = projectName;
  33.         proj.managerId = managerId;
  34.         proj.startDate = startDate;
  35.         proj.endDate = endDate;
  36.         proj.customerId = customerId;
  37.         proj.projectDescription = projectDescription;
  38.         proj.projectStatus = projectStatus;
  39.         proj.started = started;
  40.         proj.completed = completed;
  41.         proj.accepted = accepted;
  42.         proj.closed = closed;
  43.         return proj;
  44.     }
  45.     ...
  46. }


 
Donc ... je fais quoi moi ? :D Les DAO peuvent accéder à la couche métier, ou faut surtout pas et on utilise un TransfertObject redondant ?

Reply

Marsh Posté le 03-05-2007 à 21:57:48    

Pour ma part:
Mon DAO ne connait pas la couche métier dans la mesure où il ne gère pas de métier, par contre il me sert à remplir de objets métiers (ou des collections d'objet).
 
C'est ma couche de service qui va gérer les appels DAO et orchestrer les actions sur les objets métiers . Cette même couche transformera les bean métier en transfert object pour les communiquer à une couche facade qui les transferera ensuite vers la couche de présentation.
 
Le transfert object n'est pas nécessairement une recopie du bean métier, il est plus orienté présentation et contient les champs que je souhaite afficher (qui ont pu subir un traitement comme une mise en forme de date)  
 
 
 [:prettysmile]

Message cité 2 fois
Reply

Marsh Posté le 03-05-2007 à 22:02:53    

prettysmile a écrit :

Pour ma part:
Mon DAO ne connait pas la couche métier dans la mesure où il ne gère pas de métier, par contre il me sert à remplir de objets métiers (ou des collections d'objet).
 
C'est ma couche de service qui va gérer les appels DAO et orchestrer les actions sur les objets métiers . Cette même couche transformera les bean métier en transfert object pour les communiquer à une couche facade qui les transferera ensuite vers la couche de présentation.
 
Le transfert object n'est pas nécessairement une recopie du bean métier, il est plus orienté présentation et contient les champs que je souhaite afficher (qui ont pu subir un traitement comme une mise en forme de date)  
 
 
 [:prettysmile]


saluuuuuttt !!!!! [:prettysmile] [:prettysmile] [:prettysmile]
ça boume ? [:cupra]


Message édité par Harkonnen le 03-05-2007 à 22:03:10

---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 03-05-2007 à 22:05:59    

hello!!
 
pas mal, oui.
 
y a un moment que je n etais pas passée dans le coin, l'ambiance à l'air d'être toujours bonne, et j 'ai reconnu quelques pseudo, il est donc possible de vieillir sur ce forum!

Reply

Marsh Posté le 03-05-2007 à 22:22:05    

ouais.... certains d'entre nous ont "fété" leurs 7 ans d'inscription en février... :sweat:

Reply

Marsh Posté le 04-05-2007 à 02:39:01    

prettysmile a écrit :

Pour ma part:
Mon DAO ne connait pas la couche métier dans la mesure où il ne gère pas de métier, par contre il me sert à remplir de objets métiers (ou des collections d'objet).


Si le DAO remplit des objets métiers, on peut dire qu'il connaît la couche métier non ? ^^ Donc ça c'est acceptable pas de souci ?
 

prettysmile a écrit :


C'est ma couche de service qui va gérer les appels DAO et orchestrer les actions sur les objets métiers . Cette même couche transformera les bean métier en transfert object pour les communiquer à une couche facade qui les transferera ensuite vers la couche de présentation.


Hmm ça voudrait dire que je fais encore de la merde dans mon design ?  :whistle: Je développe en MVC, le controller lance des actions sur le model, et transmet les objets de la couche métier directement à la vue pour affichage. Ca se fait pas en java de transmettre des objets de la couche métier à la vue ? :D
 

prettysmile a écrit :


Le transfert object n'est pas nécessairement une recopie du bean métier, il est plus orienté présentation et contient les champs que je souhaite afficher (qui ont pu subir un traitement comme une mise en forme de date)


oki bon au moins ça confirme ce que je pensais du Transfer Object : très proche de ta classe métier au niveau des attributs, mais avec seulement ce qui t'intéresse.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed