Java

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

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Séparer la couche d'accès aux données : TransfertObject

Djebel1

Nul professionnel

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 ?

Publicité

jbourdellon

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...

Djebel1

Nul professionnel

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

Code :

public class Customer
{
public String firstName;
public String lastName;
public int customerId;
...
}

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

Code :

public class CustomerBeans
{
public String firstName;
public String lastName;
public int customerId;
...
}

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

jbourdellon

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

Djebel1

Nul professionnel

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 :

// Transfer Object to hold the details for Project
public class ProjectTO implements java.io.Serializable {
public String projectId;
public String projectName;
public String managerId;
public String customerId;
public Date startDate;
public Date endDate;
public boolean started;
public boolean completed;
public boolean accepted;
public Date acceptedDate;
public String projectDescription;
public String projectStatus;
// Transfer Object constructors...
}

Example 8.4 Implementing the Transfer Object Pattern - Entity Bean Class

Code :

public class ProjectEntity implements EntityBean {
private EntityContext context;
public String projectId;
public String projectName;
public String managerId;
public String customerId;
public Date startDate;
public Date endDate;
public boolean started;
public boolean completed;
public boolean accepted;
public Date acceptedDate;
public String projectDescription;
public String projectStatus;
private boolean closed;
// other attributes...
private ArrayList commitments;
...
// Method to get Transfer Object for Project data
public ProjectTO getProjectData() {
return createProjectTO();
}
// method to create a new Transfer Object and
// copy data from entity bean into the value
// object
private ProjectTO createProjectTO() {
ProjectTO proj = new ProjectTO();
proj.projectId = projectId;
proj.projectName = projectName;
proj.managerId = managerId;
proj.startDate = startDate;
proj.endDate = endDate;
proj.customerId = customerId;
proj.projectDescription = projectDescription;
proj.projectStatus = projectStatus;
proj.started = started;
proj.completed = completed;
proj.accepted = accepted;
proj.closed = closed;
return proj;
}
...
}

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

prettysmile

Sourire est un devoir social

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

Harkonnen

Modérateur
Un modo pour les bannir tous

prettysmile a écrit :

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

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

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

prettysmile

Sourire est un devoir social

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!

Harkonnen

Modérateur
Un modo pour les bannir tous

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

Djebel1

Nul professionnel

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 ?

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.

FORUM HardWare.fr

Programmation

Java

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

Sujets relatifs
Access 2000 ajoute données partielle	Accès fichier sur serveur distant
Prob : Type de données VB6 et SQL Server	Mysql - Compression de données texte / index fulltext ?
Mettre en route une base de données Mysql svp	Pocket PC et accès base de données distante
Idée droit d'accés	Mettre en tableau des données entrelacées
problème controle d'accès avec cookie
Plus de sujets relatifs à : Séparer la couche d'accès aux données : TransfertObject

Page générée en 0.067 secondes