Discussion :

[brice01]

Bonjour,

J'ai une appli structurée en couche BLL DAL avec des BO.
Les BO correspondent aux tables du SGBD.
Actuellement, j'imbrique (composition d'objet du type classe) les BO entre elles.
ex:

classe commande
numero
date
....
idclient

boclient client

classe lignecommande
idcommande
idarticle
qte
.....
boarticle article
bocommande commande

classe article
idarticle
code
libelle

classe client
numero
nom
idregtva

boregtva

classe regtva
idregtva
code
libelle
taux


Dans ma DAL pour lignecommande j'ai une requete SQL avec des jointures sur les tables annexes telles que commande, client,regtva ...
Avec 1 requete SQL je recupere tous les objets dont j'ai besoin et c'est pratique.
Ici j'ai une profondeur de 4 niveaux :
lignecommande -> commande -> client -> regtva

La structure des BO telle quelle est une pratique correcte pour gérer les relation entre BO ?
N'est ce pas trop lourd en terme d'allocation mémoire (espace mémoire et temps de traitement de l'allocation) ?

Pour quelques lignes et quelques BO par ligne (ici 5 BO par ligne de commande) ca va mais pour quelques centaines de lignes et quelques dizaines de BO par ligne ca commence à impacter le temps de traitement.

Du coup je me demande si ma facon de faire est correcte.

Merci pour vos avis

[Luckyluke34]

Salut,

Le nombre d'objets en mémoire n'est clairement pas le principal point d'achoppement des performances d'une application. Si tu fais le calcul toi-même de l'espace mémoire pris par les données des classes de ton exemple, c'est ridiculement petit. En prenant en compte le multi-utilisateurs comme dans le cas d'une application web, 1000, 10 000, 100 000 objets n'est généralement pas un problème pour un serveur de taille moyenne ; les plateformes et machines virtuelles bénéficient par ailleurs du fruit de dizaines d'années de recherche pour manager la mémoire, c'est très bien optimisé. Certains langages de programmation basés sur la JVM ou la CLR génèrent d'innombrables objets en arrière-plan (typiquement un objet par fonction pour les langages fonctionnels) et ça tourne sans sourciller.

Le goulet d'étranglement se trouve plutôt au niveau des I/O : accès disque, accès réseau (donc base de données), etc. C'est là que le volume se fait ressentir sur les performances, pas parce que trop d'objets encombrent la mémoire du serveur d'application mais parce que ces entrées-sorties disque ou réseau sont beaucoup plus lentes et que les données mettent beaucoup plus de temps à transiter qu'une simple allocation et copie en mémoire.

Donc en général on essaie de limiter le volume de données chargé en une fois depuis la base et pas forcément le volume de données qui s'accumule en mémoire au fil du temps (en plus celles-ci finiront par être garbage collectées). Il y a des stratégies comme la notion d'Agrégat de l'approche Domain Driven Design qui permettent de concevoir de petites grappes d'objets métier bien délimitées pour ne pas charger trop de choses à la fois. Une autre solution est le lazy loading proposé par la plupart des mappers relationnel-objet qui va donner l'illusion que tout le graphe d'objets est chargé mais qui en réalité ne va charger par exemple que la Commande et va faire des requêtes supplémentaires en base à la volée lorsqu'on essaie d'accéder à ses LigneCommande. Cependant, cela peut avoir un effet "mitraillette à requêtes" qui peut aussi grever les performances.

[brice01]

Bonsoir,

Donc mon approche est correcte.
Je vais me renseigner sur l'agrégat de DDD.

Merci pour ta contribution.