Discussion :

[brice01]

Pour un dev en couche un créé par exemple :
une couche IHM
une couche BLL
une couche DAL
un BO utilisé dans ces couches

Ensuite soit un BO Préparation composé d'un BO LigneCommande lui même composé d'un BO EnteteCommande lui même composé d'un BO Client.

Une BLL manager et une DAL est créé pour chaque BO afin de gérer ces objets individuellement.

Pour créer un Bordereaux de livraison (BL) je livre une Préparation. Donc une BLL manager pour le BL avec une méthode LivrerPreparation.
Cette méthode a besoin d'info dans LigneCommande, EnteteCommande et Client pour appliquer les regles de gestion.
Si on utilise les DAL de chaque BO on a 4 requête SQL (donc 4 aller-retour vers le SGBD). Bonjour les perf si c'est en réseau et que cela implique 8 DAL !
Alors que si on crée une nouvelle méthode dans la DAL avec une requête avec jointure... qui alimente les différents BO, on 1 seul aller-retour.

De plus tout n'est pas nécessaire (membres) dans la BO alors quel est l'intérêt de tout récupérer avec la requête SQL ?
Si tout n'est pas récupérer alors les méthodes de la BLL de base (CRUD) ne peuvent pas fonctionner correctement.

Pour conclure le dev en couche (décomposition en éléments simples et réutilisables) est il incompatible avec les perf d'accès aux données ?
Comment faites vous pour concilier les 2 ?

MERCI

[wiztricks]

Essayez d'introduire le temps dans votre réflexion.
Avant de produire, il faut un ordre de production relié à la ligne de commande. Cet ordre de production peut être crée à la saisie de la commande ou la ligne de commande dans un état particulier.

Va-t-on y mettre des références à d'autres tables ou des "valeurs"?

Et si on met des "valeurs" aura-t-on vraiment des soucis d'intégrité : est ce que l'adresse de livraison du client peut changer avant la livraison? A quel moment j'ai besoin de connaitre sa valeur actuelle?

Si nous souhaitons garder des références pour préserver l'intégrité dans un système distribué, ces références sont-elles associées à des entités dont les attributs évoluent vite ou pas?

Pourquoi faire une requête à la BDD pour récupérer certains attributs 'client' qui évoluent peu: peut-on mettre ces informations en cache? dans une copie locale d'informations clients mises à jour de temps en temps ?

Note: A l'instant t la valeur d'un attribut est A, si en t+1 elle devient B quelle est l'implication d'une prise en compte de ce changement qu'en t+2?

Si la commande est partie en livraison, elle est partie vers la mauvaise adresse et quelle que soit la vitesse à laquelle l'information sera propagée, le bon de livraison est déjà imprimé.

Que se passe-t-il si l'unité de notre +1 et +2 sont exprimés en: jour, heure, minutes, secondes,... La contrainte sur la BDD - fonction de persistance - n'est pas du tout la même.

- W

[brice01]

Merci pour ta contribution, mais je pense que ma question n'est pas comprise.

Je reformule donc ...

Chaque BLL a une méthode appelant sa méthode DAO pour récupérer les données et les mettre dans un BO.

Si un BO imbrique plusieurs BO en cascade (BL-->Préparation-->Commande)
la lecture d'un BL implique la lecture en cascade de la préparation puis de la commande pour renseigner chacune des BO.

Cette lecture entraine x requête SQL alors qu'une suffit pour récupérer l'ensemble des données des BO (requête SQL avec jointure).

Dans certain cas la lecture que la BO "BL" est utile car les autres données des autres BO ne sont pas utiles.

Créer un méthode spécifique pour récupérer l'ensemble des données pour les BO est il contraire au dev en couche (réutilisable.....) ?
Un spécialiste de SGBD dirait oui ! .. mais un développeur objet dirait quoi ?

Si oui alors comment avoir de bonne perf d'accès aux données ?

[Tommy31]

la lecture d'un BL implique la lecture en cascade de la préparation puis de la commande pour renseigner chacune des BO.

Si tu utilise un outil d'ORM, il propose différentes stratégies de récupération des objets. Il est vrai qu'habituellement, c'est la stratégie lazzy qui prime, puisqu'elle économise sur le volume de données, mais dans le cas que tu évoques, un chargement complet peut être envisagé.

Si tu n'utilises pas d'ORM, libre à toi de faire la requête que tu penses être nécessaire pour assurer la performance.

[wiztricks]

Si un BO imbrique plusieurs BO en cascade (BL-->Préparation-->Commande)
la lecture d'un BL implique la lecture en cascade de la préparation puis de la commande pour renseigner chacune des BO.

Implique parce que la modélisation en couche est insuffisante pour...

Créer un méthode spécifique pour récupérer l'ensemble des données pour les BO est il contraire au dev en couche (réutilisable.....) ?
Un spécialiste de SGBD dirait oui ! .. mais un développeur objet dirait quoi ?

Le spécialiste SGDB pourrait créer une View i.e. une sorte de table qui aggrége les informations nécessaires à chaque BO indépendamment de là ou sont les informations: il a ajouté une couche au dessus des tables.

Le spécialiste en applications distribuées dira ce que j'ai dit hier: travailler sur le temps, les données de référence et la construction à partir de là de données intermédiaires en étant moins scolaire sur les règles d'intégrité.

Le développeur objet n'a pas grand chose à dire car si on peut construire une architecture distribuée avec de la programmation objet, ses qualités non fonctionnelles (performances,...) ne sont pas de son ressort.
Les résultats seront incertains: çà pourra être excellent ou catastrophique ou dans une positions intermédiaires.

Il faut donc préciser les contraintes, comment les prendre en compte, travailler sur les interfaces pour qu'elles transportent des données utiles, mettre des caches, ....
Des tas d'activités qui relèvent de l'architecture et non de la programmation à proprement parler.

Note: Un avantage des framework est qu'on peut toujours espérer s'en sortir côté perf en multipliant le matériel pour peu qu

-W

[wiztricks]

Si tu utilise un outil d'ORM, il propose différentes stratégies de récupération des objets. Il est vrai qu'habituellement, c'est la stratégie lazzy qui prime, puisqu'elle économise sur le volume de données, mais dans le cas que tu évoques, un chargement complet peut être envisagé.
.

Le lazy loading peut aboutir a des données non consistantes.
Derrière l'ORM à son propre cache: l'application doit gérer les états des différents objets (transient / attaché / détaché) "à la main" - i.e. le developpeur doit - pour que les fonctionnalités de base d'un SGDB (ex: CRUD) puissent être remplies.

La gestion 'propre' des différents cas de figures est masquée dans l'implémentation. Les tests fonctionnels peuvent très bien passer mais si on se donne la peine de secouer un peu le bazar, ça grouille de bugs.
En plus pour valider une telle implémentation, il faut imaginer des tests qui ne sont pas du tout fonctionnels: autrement dit difficiles à définir et à construire quand ce n'est pas simplement impossible par explosion de la combinatoire.

De fait, pour utiliser ces fonctionnalités dans des applications sérieuses, il faut beaucoup plus d'expertise que n'ont les développeurs qu'on peut s'offrir ou qui existent sur le marché.

Imaginons que vous ayez eu la chance de tomber sur des bons pour la V1.0.
Avec qui réaliser la V2.0: les développeurs initiaux seront partis pour d'autres aventures, la nouvelle équipe risquera de se prendre les pieds dans le tapis. Les coûts d'évolutions seront démesurées par rapports à l'importance des nouvelles fonctionnalités ajoutées...

De vraies bombes à retardement dans les SI.
-W

[Tommy31]

Le lazy loading peut aboutir a des données non consistantes.

Dans quel cas ?

Derrière l'ORM à son propre cache: l'application doit gérer les états des différents objets (transient / attaché / détaché) "à la main" - i.e. le developpeur doit - pour que les fonctionnalités de base d'un SGDB (ex: CRUD) puissent être remplies.
-W

Le cache a une fonction supplétive. Dans de nombreux contextes, elle apparaît très vite indispensable, avec ou sans outils de mapping. Par contre, bien évidemment, elle n'est pas neutre et s'accompagne de précaution d'emploi.

De vraies bombes à retardement dans les SI.

Mouaih. Je ferais pas de prosélytisme en faveur des outils de mappings, considérant qu'ils sont lacuniers au même titre que d'autres solutions. Cependant ils permettent un continuum objet dans le code (c'est bien là l'effet recherché), et ça, ce n'est pas négligeable.

[brice01]

Je ne connait pas grand aux architectures distribuées.
Dans mon cas je suis dans un modèle client/serveur classique.

Donc si je comprend bien il n'y a rien de déconnant à faire une méthode spéciale pour agréger les données et obtenir les meilleurs performances possibles.

Cela implique que le développeur objet ai de bonnes connaissances en SGDB.

[wiztricks]

Dans quel cas ?

Dans le cas ou c'est utilisé sans précaution comme tous les caches.

Mouaih. Je ferais pas de prosélytisme en faveur des outils de mappings, considérant qu'ils sont lacuniers au même titre que d'autres solutions. Cependant ils permettent un continuum objet dans le code (c'est bien là l'effet recherché), et ça, ce n'est pas négligeable.

Je ne fais pas de prosélytisme 'contre', je dis seulement que les faire fonctionner correctement n'est pas une mince affaire.

De plus, puisque le sujet du topic est sur les "couches", l'ORM par nécessité de performance se retrouve a faire remonter dans les couches applicatives des problématiques de gestion d'états de lignes de caches du à la façon dont il travaille avec la couche de persistance.
Note: ce qui n'est pas très cohérent avec les attendus d'une architecture en couche.
- W