Discussion :

[Invité]

Bonjour,

J'ai une application qui utilise des données dans une BDD.
J'ai un Objet Client avec des méthodes getName(), setName().

J'hésite sur un aspect :
- faut-il créer une méthode Client.save() qui sauveras les données dans la BDD et le constructeur iras rechercher les données dans la BDD.
- faut-il écrire getName() qui iras chercher le nom dans la BDD et setName() qui iras ajouter/metter à jour le nom dans la BDD ?

Merci

[thibaut]

Mais quel est le context pluis en détails ?

[Invité]

Le contexte ?

Et bien, je travaille sur une "grosse" application Standalone.
Chaque "client" possède une connection au SGBD (MySql).
Et j'ai plusieurs objets avec une vingtaine d'attributs ( et donc de getters et de setters)..

[divxdede]

Hibernate peut etre une solution envisageable dans ton cas.
Jettes y un oeil.

[Invité]

Oui je sais que Hibernate pourrait m'apporter une solution. Mais
- Je ne connais pas (encore) Hibernate et je n'ai plus vraiment le temps de l'apprendre pour ce que je veux faire.
- Je me demande quel est la meilleure des solutions. Des petites requêtes pour accéder aux attributs ou une grosse requête pour tout charger en une fois.
C'est aussi et surtout dans un but théorique cette question.

Alors imaginons que java ne sois pas un superbe langage dotté de trés nombreuses API's et d'une communauté trés active et trés compétentes...
Quel serait la meilleure approche dans ce cas ?
des méthodes get..() et set..() qui accédent à la DB pour chaque attribut ou un constructeur et une méthode save qui chargent/sauvent tous les attributs..
Dans les cas des getters et setters je ferais un truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
private String nom;
...
public String getNom() {
    if ( nom == null ) {
        nom = /* Requête dans la DB */
    }
    return nom;
}

[sinok]

Perso je me prononcerais plutôt vers des requêtes chargeant directement un objet voire une liste d'objet.
A part ça sur la méthode, au dieu de faire directement les appels dans les objets en question je passerais plutôt par l'emploi du pattern DAO qui permet de créer une surcouche permettant de lier tes beans à la base de donnée et donc bien séparer ton code.

Comme d'hab direction un tuto de sun à ce sujet:

http://java.sun.com/blueprints/corej...essObject.html

[Invité]

Ok, merci beaucoup.
En fait pour l'instant j'ai une classe Listing qui me charge des collectiosn d'objets.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Collection clients = Listing.getListeClients();

Comme d'hab direction un tuto de sun à ce sujet:
http://java.sun.com/blueprints/corej...essObject.html

Erf, je ne trouve jamais les bons tutos quand il faut..

[BizuR]

Idem pour mon avis, je passerai *au moins* par une couche DAO, à défaut d'utiliser Hibernate (qui, cela dit, n'est pas forcément des plus compliqué à assimiler ).

Sinon pour tes deux idées :
1- Accéder à la BDD a chaque getter/setter et une très mauvaise solution. Si l'application est trop fortement utilisée (et par de nombreux utilisateurs), imagines le nombre d'accès en base, de requetes exécutées ... ton serveur de BDD lachera dans la demi-heure (ou bien la file d'attente sera pleine si tu utilises un pool de connexion).

2- Utiliser une méthode save() semble alors la meilleure solution si l'on considère uniquement le nombre d'appels en base à limiter. Toutefois, dans un esprit de développement en entreprise et afin de limiter la maintenance à une partie restreinte de ton application (plutot que de faire du JDBC dans chaque classe), il est utile (voire important, primordial, enfin c'est au choix ) de séparer les couches logiques* de ton application. Ainsi, au même titre que ton objet "Client" ne renverra pas une méthode avec l'IHM (genre un panel client), ce dernier ne devrait normalement pas accéder à la base de données, mais faire appel à une couche différente (celle appelée DAO).

Libre à toi donc de faire comme tu préfères, mais centraliser les accès en base reste assez indiqué. Tu peux maintenant envisager deux types d'accès :
- couche DAO (un objet DAO gère un objet du modèle métier ex : Client possède son ClientDAO pour save(), load(), delete(), etc.)
- service de persistance : un objet qui sauvegardera n'importe quel objet métier de ton application (hibernate le fait, par exemple)

Tu peux également cumuler les deux et permettre ainsi des traitements spécifiques à certains objets. Au délà d'Hibernate, il existe d'autres outils intéressants et moins complexes à mettre en oeuvre comme Ibatis par exemple, qui propose une solution d'externalisation de la couche SQL (+mapping Objet/Relationnel) si tu préfères utiliser une couche DAO

Voila, si tu as des questions, n'hesites pas

[Invité]

Ok,

Merci beaucoup. Je vais donc passer progressivement avec une couche DAO pour mes classes. Si je comprend bien, la couche DAO fait partie du ou est le 'M' de 'MVC'.

Pour ce qui est d'hibernate,je n'ai jamais dis que c'était compliqué juste que je ne pouvais pas me permettre de lire la doc pour le moment (et je ne sais pas non plus si l'application en vaut la peine).

Client possède son ClientDAO pour save(), load(), delete(), etc.)

C'est à dire que client contient un objet ClientDAO ?
-> ha non, je n'ai rien dis désolé ( je n'avait pas encore parcourus le document de sun.. )

[BizuR]

Ah ui, pardon, je m'étais mal exprimé à ce sujet, j'en conviens

Pour le M ... on peut voir cela ainsi en effet mais j'aurai plus tendance à le sortir du modèle MVC, il vient plus s'interposer entre le M (qui, en soi, représente l'ensemble de ton modèle métier) et la base de données ... un peu comme une couche supplémentaire. Maintenant, quitte à le rentrer dans une des trois lettres, oui, il se situerait dans le M

En gros donc, pour mieux m'exprimer, je dirai qu'à chaque classe métier correspondra un DAO (ex : si il existe une classe Client, il existera une classe ClientDAO) voila, tu l'as apparemment compris, mais je précisais pour ceux qui liraient ce post plus tard

[Invité]

D'accord, ça se clarifie de plus en plus.
Il ne me reste qu'a commencer à l'utiliser pour me/vous poser d'autres questions..



je ne marque donc pas le post "résolu" tout de suite mais je ne l'oublie pas.

[Invité]

Dans les documents de BluePrints, on fait souvent référence à des Transfer Object
J'ai bien trouvé un lien vers ce pattern mais si quelqu'un pouvais me faire une petite introduction en Français..

Merci

[BizuR]

Les transferts objects sont les DTO ... il me semble que c'est encore une autre couche aux DAO. Menfin je ne saurais te renseigner minutieusement sur le sujet puisque moi même je n'en suis pas très connaisseur

Tout ce que je dirai est que, d'apres ce que j'ai lu, Hibernate semblerait remplacer cette couche DTO (qui sert essentiellement a gerer les états des objets il me semble).

[Invité]

Les transferts objects sont les DTO

Oui c'est ça.

... il me semble que c'est encore une autre couche aux DAO.

Oui mais ils ont l'air assez liées quand même..
--> http://java.sun.com/blueprints/corej...essObject.html
Figure 9.1 Data Access Object
Figure 9.2 Data Access Object sequence diagram
Example 9.5 Customer Transfer Object