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

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?

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.

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.

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.

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.

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.

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.