À quoi sert une couche logique métier (BLL)?

14

En lisant les bonnes pratiques pour les applications de base de données, j'ai souvent rencontré des partisans des soi-disant "couches de logique métier" et j'essaie de décider s'il est préférable que mon projet en utilise une (c'est un petit projet personnel). Mon problème réside dans le fait que je ne peux penser à rien pour le BLL que le DAL ne puisse pas déjà gérer (exécuter des requêtes et mapper les résultats sur des objets), donc mon BLL appelle simplement le DAL sans rien faire lui-même.

Peut-être que je me trompe sur ce que le DAL devrait faire aussi. Mais quelle que soit la nature des fonctionnalités à attendre d'un BLL dans une application de gestion de base de données?

Andrew Arnold
la source
Cela ressemble à un dilemme efficacité vs flexibilité / réutilisation de code.
Job
@Job - Oui, en quelque sorte, d'autant plus que c'est une petite application avec peu de chances de réutilisation de code (pour l'instant). Mais il essaie également en partie d'utiliser les meilleures pratiques possibles.
Andrew Arnold
J'ai voté pour tout le monde parce que ce sont toutes d'excellentes réponses; malheureusement je ne peux en accepter qu'un.
Andrew Arnold

Réponses:

10

Pour mes applications plus petites, mon BLL commence généralement comme un relais vers le DAL. Je suis d'accord avec ça. Au fur et à mesure que je "découvre" les règles métier, le BLL est l'endroit où je les mets. Je finis également par trouver beaucoup de choses nécessaires dans le BLL pendant que j'écris mes tests. Pour mes propres applications personnelles, je fais les règles de l'entreprise et le BLL est toujours là où je les mets. Pour moi, le BLL est quelque chose qui grandit avec le temps. Plus je travaille sur un projet depuis longtemps, plus son BLL est grand.

Envisagerais-je de combiner le BLL et le DAL pour un petit projet? Je pourrais, sauf pour le fait que je change les technologies DAL aussi souvent que je change de coiffure, et j'aime avoir quelque chose pour isoler mon code client de cela.

Marcie
la source
2
Je n'ai pas changé de coiffure depuis 20 ans. Je détesterais changer ma technologie DAL aussi souvent que je change de coiffure.
Erik Funkenbusch
3
Certaines personnes ne mettent à jour leur DAL que tous les 20 ans!
Marcie
4
Bonne réponse. Il est courant que les petits projets n'aient vraiment pas grand-chose à mettre dans le BLL. Il est également courant que les petits projets grossissent, et si vous n'aviez pas au moins un shell de BLL en place, la quantité croissante de logique va s'accumuler dans la couche de présentation ou le DAL, aucun des deux n'étant particulièrement souhaitable.
Carson63000
5

Le BLL traiterait des choses qui font partie du domaine d'activité, pas une partie de la base de données et pas une partie de l'interface utilisateur (généralement). Par exemple, utiliser l'âge d'un client pour déterminer s'il peut bénéficier d'une remise spéciale pour les seniors. Le DAL ne devrait pas faire cela, il devrait simplement récupérer les données client, puis les stocker avec les données de remise une fois que le BLL a fait son travail. Le DAL devrait se concentrer davantage sur CRUD. Dans les petites applications, les deux préoccupations peuvent se chevaucher.

FrustratedWithFormsDesigner
la source
En fait, cela fait partie du problème lorsque vous essayez d'isoler des "niveaux" ou des "couches" comme celui-ci. Souvent, quelque chose doit traverser des couches car il convient mieux à cette couche différente. Un bon exemple est les requêtes SQL qui ont une logique métier intégrée. Votre calcul d'âge, par exemple, pourrait être entièrement effectué dans la couche SQL (ou ORM) plus efficacement.
Erik Funkenbusch
2
@Mystere Man Plus efficacement est subjectif. Ce commentaire signifie que vous savez ce qui se passe sur le front-end. Il est de nature très statique. Utilisez les requêtes SQL pour optimiser les données à coup sûr, mais il y a une ligne fine lorsque vous commencez à lier une interface utilisateur au back-end.
Aaron McIver
1
@Mystere Man: En effet, c'est possible. Et il est souvent vrai que les choses "saignent" d'une couche à l'autre. Le véritable art est de les séparer et de les maintenir séparés. Je sais, ce n'est pas toujours facile ...
FrustratedWithFormsDesigner
1
Et boom , l'optimisation prématurée lève la tête laide! J'ai du mal à imaginer qu'une simple comparaison de dates soit un tel goulot d'étranglement qu'elle justifie de déplacer une règle métier vers le DAL. La maintenabilité devrait également être un objectif, pas seulement la vitesse.
TMN
5

Andrew,

Les couches de logique métier sont ce que vous obtenez lorsque vous effectuez un développement piloté par domaine et que vous vous concentrez sur les activités principales du domaine. Si vous supprimez la couche de présentation (gui, web) et la couche d'infrastucture (db, connectivité réseau, etc.), vous avez les principales activités qui font partie de votre domaine, telles que le dépôt d'argent sur un compte bancaire. Maintenant, si vous avez modélisé votre couche métier et l'avez isolée de la présentation et des infrastructures, vous pouvez la porter facilement vers d'autres utilisations, telles que le Web ou les appareils mobiles. C'est une façon propre de penser au développement et d'après ce que j'ai vu, cela n'est malheureusement pas pris au sérieux.

Je recommanderais de mettre la main sur Eric Evans - Domain Driven Design, qui est un bon livre qui justifie de concentrer les efforts de développement sur le domaine. Certes, c'est un peu une lecture à sec à mi-chemin, mais cela crée un élan et a de fortes convictions quant à ce que les développeurs font mal avec les systèmes d'aujourd'hui.

Planète désolée
la source
4

Rien ne dit que vous DEVEZ avoir un certain nombre de niveaux ou de couches. Tout dépend de la complexité de votre projet. Jetez un œil à la plupart des exemples d'applications MVC, comme le nerd dinner ou le magasin de disques .. ils utilisent tous 2 couches car pour les applications qui ont très peu de logique de traitement, cela n'a tout simplement pas de sens.

Cependant, même si votre application est petite, il pourrait être avantageux d'abstraire la couche de données de la couche de présentation via une troisième couche qui serait normalement une couche métier. Cela vous permet d'apporter des modifications à un seul endroit, plutôt que sur toute votre couche de présentation.

Supposons que vous décidiez de changer votre ORM de Linq en SQL en Entity Framework (ou nhibernate). Il sera probablement plus facile de le modifier dans la couche métier que dans votre couche de présentation, car la présentation est étroitement liée à son modèle de présentation.

Si vous comprenez MVC, c'est-à-dire .. Model View Controller, vous pouvez penser à votre architecture d'application en termes similaires. Le modèle est analogue à votre couche de données, la couche de présentation est la vue et la couche métier est le contrôleur.

Erik Funkenbusch
la source
4

En complément de la réponse de Desolate Planet sur la conception pilotée par domaine:

Découvrez également The Onion Architecture , qui est très aligné avec les concepts de conception pilotée par domaine.

Remarquez comment la «couche» de Business Logic est le cœur de l'oignon et chaque couche d'infrastructure (telle que la couche d'accès aux données) sont ses dépendances externes. Cela aide beaucoup à tester, car vous devriez pouvoir vous moquer de chaque dépendance de l'infrastructure externe et tester entièrement la logique de votre domaine.

À mon avis: le Business Logic Layer est l'endroit où réside la «solution conceptuelle pure». Les autres ne sont que des détails de mise en œuvre des infrastructures.

Cependant, certaines applications peuvent ne pas avoir besoin de ce type d'architecture. Si toutes vos applications sont des opérations CRUD de jeux de données, votre «solution conceptuelle pure» pourrait en fait être pratiquement vide et tout ce dont vous avez besoin est un frontal d'édition de base de données. Dans ce cas, vous devriez probablement vous concentrer sur les couches DAL et UI uniquement.

Sergio Acosta
la source
1

La réponse à cette question est (à mon humble avis): "puis-je remplacer mon DAL complètement et ne pas avoir à réécrire mon code de logique métier"?

Pensez-y comme à votre couche de présentation - il est assez courant de penser à changer l'interface graphique pour une autre, une interface graphique de bureau épaisse est échangée contre un client Web, qui est échangée contre une application iPhone. Ce n'est pas si courant de penser comme ça pour BLL / DAL car ils ne sont jamais vraiment échangés, sauf peut-être pour quelque chose de très similaire (par exemple, une base de données SQLServer remplacée par une base MySQL), mais si vous imaginez que vous deviez changer votre base de données en un stockage distribué accessible à l'aide d'une API, vous pourriez avoir une idée plus précise de l'endroit où les couches se rencontrent.

gbjbaanb
la source