Envoyer un Entity à une application Client

Bonjour,

Je crée un application type client/serveur avec un serveur java EE et un client lourd java, j'utilise JPA pour la persistance. Je serai probablement amené à développer d'autre type de client pour cette application.

Je me pose plusieurs questions sur la meilleur manière façon d'échanger des données avec l'application client. J'ai lu pas mal de choses sur le sujet mais beaucoup qui se contredisent.


On parle souvent d'utiliser des DTO pour faire circuler les données mais dans mon cas, la plus part du temps, les DTO ont exactement la même structure que mes Entity (les annotations en moins). Je trouve donc dommage de faire le boulot deux fois et surtout de devoir modifier à deux endroit différent dès que quelque chose change. (Ou peut-être ai je une mauvaise conception de ce que doit être un DTO).

Je me demande donc quelle pourrait être les problèmes si j'utilise directement les Entity pour transférer les données. ( Ce qui implique donc d'inclure mon projet JPA dans mon projet "client").

Pour clarifier un peu, voici un exemple de ce que je voudrais faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

@Entity public class Person{ @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id; private String firstName; private String lastName; }   @Remote public interface PersonRemote { public Person getPersonByName(String name); }

---

Est-ce que cela peut être considéré comme une mauvaise pratique? Est ce que ça peut engendrer des problèmes d'évolutivité pour l'application?

Pour le moment, le projet est assez simple mais il devrait beaucoup se développer dans les années à venir.

N'étant pas un professionnel du développement, j'aimerais avoir l'avis de développeurs expérimentés.

Merci d'avance pour vos réponses.

Dans ton cas l'entité est simple (que des champs "primitifs", j'inclus le String dedans), cependant imaginons que dans ton entité Person tu ais une Enterprise, qui contient elle plusieurs entités Business Unit, qui elles possèdent plusieurs Activity.

Ton Entité devient un monstre, et transmettre ça prendra beaucoup plus de temps que si tu étais passé par le pattern DTO.

Au lieu d'avoir :

Code:

---

1 2 3 4 5 6 7 8 9 10

@Entity public class Person{ @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id; private String firstName; private String lastName; private Enterprise enterprise; }

---

avec la lourdeur que l'entité enterprise sous-tend, on aurait

Code:

---

1 2 3 4 5 6 7 8 9 10

@Entity public class Person{ @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id; private String firstName; private String lastName; private Long enterpriseId; }

---

Ici on respecte le pattern DTO, seul le pointeur vers notre entité est transmis, et ça pèse moins lourd dans la communication, on laisse le back-end se charger de la reconstruction.

Merci pour cette réponse, je comprend mieux l'utilité des DTO.

Pour ma culture personnel, qu'est-ce qu'une entité Business Unit ?

Je sais pas trop j'ai juste essayé d'inventer une entité "complexe" :mrgreen:

J'ajouterais par ailleurs que si tu es amené à utiliser le pattern DTO dans ton application, par soucis d'homogénéité dans ton application utilise le partout dans tes communications front/back, même pour des entités simples.

Tu auras une meilleure scalabilitée, exemple :

Imaginons que tu ais ton DTO simple :

Code:

---

1 2 3 4 5 6

public class PersonDto{ private int id; private String firstName; private String lastName; }

---

Mais que pour des raisons X ou Y, lorsque tu envoies une nouvelle personne à ton back, tu ais besoin de connaître la valeur d'un champ "Pays" que tu connais afin de faire du traitement. (On pourrait imaginer que si "Pays" vaut Hollande, alors on met la valeur de firstName en minuscules).

Dans ce cas tu pourrais avoir :

Code:

---

1 2 3 4 5 6 7

public class PersonDto{ private int id; private String firstName; private String lastName; private String pays; }

---

Sans impacter ta modélisation d'Entité, tu as pu ajouter un traitement lors de la communication back/front.