Discussion :

[kenji_getpowered]

Bonjour,

je dois créer l'architecture d'un nouveau projet et je me pose des question de conception que je vais vous exposer.

3 objets : Projet / Pc / Template

Projet ------ possède 1..* -----> Pc
Pc ------ est de type 1 -----> Template

Donc le Pc contient l'information sur le projet et l'information sur le template

En ce qui concerne la base de données (mysql classique), j'ai donc fait ceci
PC ( numPc, etc..., numProjet, numTemplate)

je désire créer des objets représentant ces entités (avec DAO à la main)

j'envisage 2 solutions

Solution 1 - l'objet PC contient les autres objets
PC ( numPC, etc...., objetProjet, objetTemplate)
mais le problème que j'entrevois est la multiplications des requêtes (pour rapatrier et "binder" les différents objets) et la lourdeur des requêtes/objets

Solution 2 - l'objet PC est représentatifs de son équivalent en modèle physique de donnée
PC ( numPc, etc..., numProjet, numTemplate)
et si j'ai besoin d'autres infos sur le projet ou le template, je fais les requêtes à ce moment la.

Infos supplémentaires
- la BDD et l'applicatif seront sur le même serveur (a priori)
- la partie Front end et la Back end seront sur le même serveur (pas forcément besoin d'architecture n-tiers)

voila voila, je me triture l'esprit pour trouver la meilleure solution possible et si certains d'entre vous sont déjà passé par la.... ça m'aiderait grandement.

Merci

[Deaf]

Bonjour,

Dans un domaine comme celui-là, ce genre de questions se sont déjà posée. L'idée est donc d'aller voir la solution qui a été choisie pour les librairies qui se sont imposées.

En l'occurence, Hibernate permet de faire du Lazy-Loading. L'idée est d'aller chercher les objets quand ils sont demandés.

Donc l'idée est d'avoir la facilité de ta première solution (accès direct aux objets) avec les performances de la seconde (chargement à la demande). Pour t'en sortir, tu peux utiliser le principe de Proxy qui servira de tampon entre l'objet PC et l'objet Template (par exemple)

[kenji_getpowered]

Merci pour ta réponse,

Je ne peux pas utiliser Hibernate, et je vais avoir du mal à coder correctement ce principe de lazy loading, surtout que mes données vont être sérialisées (rpc) du coup j'ai peur que les données soient entièrement chargées de toute façon.

src :
http://bmarchesson.developpez.com/tu...gement/#LIII-C

[Deaf]

L'important est de bien déterminer comment vont être utilisés tes objets DAO. Est-ce que tu vas souvent avoir besoin d'exploiter les liens entre les objets?
As-tu des traitements en interne à ta couche DAO qui ont des besoins différents?

Il se peut que tes traitement internes n'aient besoin que très rarement des objets eux-même, contrairement à ta couche service. Il se peut aussi que ce soit l'inverse.

Selon le cas, tu peux prévoir deux types de chargements, ou bien faire du lazy-loading en interne.

Pour résumer, c'est à étudier.
Les librairies génériques comme Hibernate sont prévues pour être flexible et fonctionner dans différents cadres d'utilisation. Je doute que ce soit le cas de ton projet (enfin, je te le souhaite). Tu peux donc faire des choix qui te faciliteront la vie et qui imposeront des limites en adéquation avec le cadre de ton appli.

N'hésite pas à revenir vers nous

[kenji_getpowered]

Ce que je pense faire est un mix entre la solution 1 et la solution 2, je m'explique :

- Je vais créer des objets "simple" avec les éléments nécessaire pour l'affichage
(utile lors de la création de liste par exemple)

je vais créer des objets contenant les autres objets (solution 1)
(utile lors de la manipulation en front end

Cette idée vient d'un mix entre la solution de google où ils créent un objet contact et un objet contact detail (juste avec le prenom et le nom) pour l'affichage de la liste.
http://code.google.com/intl/fr/webto...hitecture.html

et une application des principes du design pattern DAO et du lazy loading.

Qu'en pensez vous?

[Deaf]

Je n'ai pas tout à fait compris ce que tu vas faire.
Ceci dit, je doute que l'on puisse te donner un avis. Pour cela, il faut confronter ta solution avec ton besoin
Sauf erreur grossière, la plupart des solutions sont acceptables dans un certain contexte.