Ca dépend du métier.

Si c'est une application bancaire commerciale, par exemple, c'est là où les règles de découvert autorisé seront implanté.

Si c'est une application de trading, c'est là où les règles de hedging seront vérifiées.

Si c'est une application d'astronomie, c'est là où les lois de la physique seront simulées.

etc...

Bonjour,

On concoit une couche BLL dans des architectures n-tiers.

En général, on a 3 couches

- Interface => interaction utilisateur (Interface Homme Machine)

- Business (BLL) => logique métier, ce qu'on va "calculer", ce qui sera concrètement fait par l'application

- Domaine, infra => accès aux données (BDD/ fichiers textes...)

Je pense que tu trouveras pas mal de choses sur google qui t'expliqueront plus en détail ces concepts.

concrètement  je ne vois pas trop l'intérêt d'utiliser la couche BLL sachant qu'elle fais appel aux Méthodes implémentés dans la couche  DAL. pourtant je trouve pense qu'on peut directement utilisé les Méthodes implémentés dans le DAL sans pour autant passé par le BLL.

cet a dire pas besoin de faire => BLL.MethodeDAL() .

Parce que si tu changes ou que tu as besoin de plusieurs types de GUI, t'es marron, faut tout refaire ou l'implémenter plusieurs fois les mêmes règles business.

T'auras l'air fin quand tu devras expliquer la facture au donneur d'ordre juste pour avoir une GUI différente.

L'objectif est de "compartimenter" ou "factoriser" chaque responsabilité de ton application.

Le fait d'utiliser ces 3 couches permets que chaque partie soit indépendante, et lorsque tu as besoin de changer quelque chose sur une de ces 3 "briques", tu n'as pas à toucher aux autres briques, car elles sont indépendantes.

Admettons que tu appeles directement ta DAL dans l'UI. Admettons aussi que tu changes de système de stockage de données, en passant d'une base de données à un fichier texte.

Tu vas devoir modifier l'UI pour appeler la nouvelle DAL. Ca peut ne pas être grand chose pour une petite application, par contre dans une application professionnelle, ca demande plus de travail, et surtout, tu risques de casser quelque chose.

On préfère généralement modifier la BLL pour appeler la nouvelle DAL, ainsi, le changement vis à vis de l'interface est transparent.

Petit point de détail => on ne fait pas BLL.MethodeDAL(). On fait BLL.MethodeBLL(), et MethodeBLL() appele une fonction de la DAL.

-
Edité par earp91 23 août 2021 à 9:24:00

Et en segmentant l'application en 3 parties, on essaie de spécifier "intelligemment" les API entre les parties pour des modifications dans les unes n'ont pas d'impacts sur les autres.

En clair, on fait en sorte que dans la "MethodeBLL", l'appel a "DAL.MethodeDAL" ne change pas même en refactorant complètement l'intérieur de la DAL.

tu peux être un peu plus claire sur cette expression : Tu vas devoir modifier l'UI pour appeler la nouvelle DAL. je crois Bien qu'avec un exemple c'est mieux.

Merci Infiniment

Si tu modifies ta DAL pour s'adapter à des contraintes de performance de dénormalisation d'une base de données, pour monter en charge mais que t'as bêtement fait un écran par table, tu fais quoi ?

Bin t'es bon pour avoir à modifier tout tes écrans et en plus, ils n'auront aucun sens pour l'utilisateur final de l'application, qui s'en fout de la dénormalisation pour augmenter les performances.

Et donc c'est comme une Injection de dépendance Alors