Classe Java correspondant une table

Bonjour.

Je vous pose une question car je suis en contact de deux personnes codant différemment, et je voulais connaitre la solution la plus "propre".

Soit deux tables

Ville :
- identifiant
- nom
- identifiant_du_pays

et
Pays :
- identifiant
- nom

La liaison est comme dans la vraie vie : une ville appartient à un pays.

Quelqu'un crée :
- une classe Ville avec les attributs identifiant, nom et identifiant_du_pays
- une classe Pays avec les attributs identifiant et nom

L'autre :
- une classe ville avec les attributs identifiant, nom et un pays de type Pays.
- une classe pays avec les attributs identifiant, nom et une collection de villes (de type Ville)

Je voulais connaitre la meilleur solution sachant qu'en faisant un "select" dans les tables, nous n'obtenons que les identifiants et non pas tout le contenu des autres tables. Car dans ce cas, je suppose qu'il faudrait faire des jointures à chaque fois entre les tables pour renseigner tous les attributs de chaque objet.

Quel est votre avis?

Cdt.

que la bonne solution dépend uniquement du contexte d'utilisation:

Si vous avec des système type hibernate etc derrière, clairement la solution consistant à intégrer le Pays est la plus simple, puisque l'ORM gère déjà tout.

Si vous y allez "a la main", la solution de l'identifiant est la plus facile à coder (on ne dois pas gérer de liste centralisée de Pays pour éviter de dupliquer les pays etc) mais la plus embetante si vous comptez "naviguer" à travers vos données (exemple afficher dans une UI le nom du pays)

Bref, c'est à voir au cas par cas, les deux solutions se valent, la deuxième est plus "objet" mais pas toujours pratique à gérer

Aujourd'hui, il n'y a aucun framework particulier. Uniquement des JSP/Servlet sont utilisées.

D'après ce que j'avais pu voir, la solution "N'avoir qu'un champs identifiant" était la solution actuellement utilisée mais cela pouvait en effet etre long lorsque on affichait une liste (exemple : la liste des villes en affichant le libellé des pays)

une options à envisager: une liste de pays unique conservée en mémoire et partagée par tous les utilisateurs (éventuellement mise à jour occasionellement), stockées dans un Map<Long,Pays> et à la lecture des ville ou l'affichage aller chercher là dedans.

Ma question était générale à l'ensemble de classe.

En utilisant du "pur objet", on risque de ne jamais s'en sortir, car un objet chargera un autre objet, qui en chargera un autre.

Peut être faudra-t-il créer de classe d'affichage pour afficher des gros tableaux avec libellés par exemple...

C'est là que des ORM sont bien utiles car ils gèrent ça. Quand il faut le faire à la main, c'est du boulot de gérer le cycle ;)

Oui, j'ai lu ça, mais pour des applis de petites tailles, ca a l'air un peu lourd à mettre en place, non?

C'est sur que si vous avez trois tables à gérer, ca vaut pas le coup. C'est finalement la question de savoir à partir de quel moment vous voulez échanger les emmerde de la gestion des relations entre vos tables et du sql par les emmerde de la gestion de la session et de cascades des ORM :mouarf: