IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre régulier
    Profil pro
    aucun
    Inscrit en
    décembre 2004
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : décembre 2004
    Messages : 96
    Points : 110
    Points
    110
    Par défaut Architecture BLL DAL BO : gestion des relation entre BO
    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

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    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.

  3. #3
    Membre régulier
    Profil pro
    aucun
    Inscrit en
    décembre 2004
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : décembre 2004
    Messages : 96
    Points : 110
    Points
    110
    Par défaut
    Bonsoir,

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

    Merci pour ta contribution.

Discussions similaires

  1. Gestion des relations entre tables
    Par Jasmine80 dans le forum DBDesigner
    Réponses: 10
    Dernier message: 09/02/2009, 15h33
  2. Récupération des relations entre tables
    Par Themacleod1980 dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 02/02/2006, 11h34
  3. Réponses: 2
    Dernier message: 22/07/2005, 12h06
  4. Réponses: 4
    Dernier message: 04/07/2002, 12h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo