Service Layer vs Business Layer dans l'architecture des applications Web?
Je sais que cela peut sembler idiot, mais j'ai du mal à comprendre le besoin d'une couche de service et ses différences avec la couche métier.
Donc, nous utilisons asp.net mvc 2 et avons une couche d'accès aux données qui effectue toutes les requêtes avec la base de données, puis nous avons la couche métier qui a la logique métier et les validations nécessaires. Enfin, nous avons le calque de présentation qui a essentiellement toutes les vues. De plus, nous avons également quelques helpers, DTO et classes viewmodel dans différents dossiers dans le cadre de nos bibliothèques. Mais j'ai essayé de lire sur l'architecture et il semble que la couche de service soit une partie importante d'une architecture.
Tout ce que je comprends, c'est qu'une couche de service est quelque chose qui appelle toutes les fonctions. Mais je ne vois pas vraiment le besoin de la couche Service dans notre application? Ou il est peut-être déjà là et je ne le vois pas ... Quelqu'un peut-il expliquer avec un exemple l'importance d'une couche de service? En quoi est-ce différent d'une couche métier parce que ce que j'ai lu semble assez similaire? Si c'est dans le premier besoin du tout? Tout ce que nous essayons de faire, c'est de concevoir notre application de la meilleure façon possible, quelles sont vos pensées et votre expérience à ce sujet?
Il s'agit de découpler votre application en morceaux autonomes, chacun étant défini par l'exigence de bien faire un travail.
Cela vous permet d'appliquer des modèles de conception spécialisés et les meilleures pratiques à chaque composant.
Par exemple, le travail de la couche métier consiste à implémenter la logique métier. Arrêt complet. L'exposition d'une API conçue pour être consommée par la couche de présentation n'est pas son "souci".
Ce rôle d'intermédiaire est mieux exécuté par une couche de service. La factorisation de cette couche spécialisée vous permet d'appliquer des motifs beaucoup plus spécialisés à chaque composant individuel.
Il n'est pas nécessaire de concevoir les choses de cette façon, mais l'expérience accumulée de la communauté indique qu'il en résulte une application qui est beaucoup plus facile à développer et à maintenir car vous savez exactement ce que chaque composant est censé faire, avant même de commencer à coder l'application.
Chaque couche devrait très bien faire un travail. Le rôle d'intermédiaire entre les performances de la couche service est un travail bien défini et c'est la raison de son existence: c'est une unité de complexité qui est conçue de la même manière encore et encore, plutôt que d'avoir à réinventer la roue à chaque fois, pour gérer ce rôle avec la logique métier à laquelle il n'appartient pas. Considérez la couche de service comme un composant de mappage. Il est externe à la logique métier et n'appartient pas non plus à ses classes, ni aux contrôleurs.
De plus, en raison de la non-prise en compte de la logique métier, vous obtenez des objets métier plus simples, plus faciles à utiliser par d'autres applications et services que "l'entreprise" consomme.
ASP.NET MVC n'est rien sinon une plate-forme pour vous permettre d'écrire vos applications en tant que composants spécialisés.
Grâce à cette compréhension croissante de la façon de spécialiser les composants, les programmes évoluent d'un bol primordial de soupe et de spaghettis vers quelque chose de différent et d'étrange. La complexité à laquelle ils peuvent faire face, tout en utilisant des structures simples, augmente. L'évolution commence. Si la vie est un événement, cela doit être bon, alors continuez à rouler.
Vous pourriez trouver le terme Astronaute d'architecture intéressant.
Le fait est que ne vous laissez pas prendre dans toutes ces "couches" autour desquelles les gens se bagarrent. Chaque fois que vous avez ajouté une couche à l'application, il doit y avoir un objectif.
Par exemple, certaines personnes réussissent à combiner les concepts d'une couche d'accès aux données et de logique métier en une seule. Ce n'est pas bon pour toutes les solutions, mais cela fonctionne parfaitement pour beaucoup d'entre elles. Certaines personnes peuvent même combiner présentation et affaires ... ce qui est un non majeur dans de nombreux cercles, mais, encore une fois, peut être parfait pour le besoin en question.
Fondamentalement, le problème que vous résolvez doit dicter la structure de l'application. Si d'autres applications doivent s'intégrer à la vôtre, une couche de service peut devoir être ajoutée. Cela peut prendre la forme de simples formulaires Web sur lesquels d'autres personnes peuvent publier des données ou aller plus loin pour être complet sur les services Web. Il peut même y avoir des situations où vous souhaitez que la couche de service soit le principal emplacement d'accès pour plusieurs présentations.
Vous pouvez devenir aussi compliqué que vous le souhaitez, mais une bonne règle de base est de rester simple jusqu'à ce que les complications deviennent nécessaires.
Dans certaines conceptions, la couche de service n'est pas utilisée par la couche de présentation.
La couche de service est appelée par d'autres applications qui souhaitent utiliser les couches métier et d'accès aux données dans l'application.
D'une certaine manière, la couche de service est un autre frontal distinct de la couche de présentation.
Voir le schéma architectural ici. Les utilisateurs accèdent à l'application via la couche de présentation. Et les systèmes externes accèdent à l'application via la couche services. La couche présentation et la couche services communiquent avec la façade de l'application dans la couche métier.
À titre d'exemple de ce que pourraient être ces autres "systèmes externes", les services Web et les services WCF appellent la couche service. Une autre application Web pourrait appeler la couche de service de cette application dans un appel de service Web. Ce serait une façon de garantir que les deux applications appliquent la même logique métier et que toutes les modifications apportées à la logique métier se reflètent dans les deux applications.
Comme le souligne Chris Lively, il ne faut pas se laisser emporter par la création de calques. Je recommanderais seulement de créer les couches qui seraient utiles dans votre application. D'après mon expérience, le besoin d'une couche service n'est pas fréquent, mais le besoin d'une couche métier est très fréquent.
La couche de service est généralement construite en termes d'opérations discrètes qui doivent être prises en charge pour un client.
Par exemple, une couche de service peut exposer la création d'un compte. Alors que la couche métier peut consister à valider les paramètres nécessaires à la création d'un compte, à construire des objets de données à conserver, etc.
Souvent, la couche de service utilise un code de style procédural ou de script de transaction pour orchestrer les couches métier et/ou logique.
Sachant cela, vous pouvez vous rendre compte que votre couche métier est vraiment une couche service également. À un moment donné, le point à partir duquel vous posez cette question étant un de ces points, la distinction est principalement sémantique.
De mon point de vue, une couche de service vous permet d'isoler votre couche de présentation de votre couche d'entreprise, de la même manière que la couche d'accès aux entreprises et aux données vous isole de la façon dont vous conservez les données.
À l'intérieur de votre couche d'entreprise, vous mettriez des éléments essentiels à votre "entreprise". Un exemple artificiel (et probablement mal conçu) consisterait à ce que ce soit le lieu où les rabais sur un produit se produisent.
La couche de service vous permet de séparer davantage l'interface de l'entreprise. Ou même échanger d'autres couches métier en fonction des scénarios changeants de l'entreprise.
Cependant, toutes les applications n'en ont pas besoin (beaucoup de variables entrent dans cette détermination), trop d'architecture peut introduire des complexités dont votre équipe n'a peut-être pas besoin.
Jetez un œil à ce que Randy Stafford dit à propos de la couche de service dans le livre "P of EAA" http://martinfowler.com/eaaCatalog/serviceLayer.html
Une couche de service définit la limite d'une application [Cockburn PloP] et son ensemble d'opérations disponibles du point de vue de l'interface des couches clientes. Il encapsule la logique métier de l'application , contrôlant les transactions et coordonnant les réponses dans la mise en œuvre de ses opérations.
Facile. Pour exposer votre logique métier à un client, utilisez une couche de service. Demande toi:
Lors de la modification de la logique métier, la couche de service doit-elle changer? Si la réponse est "pas toujours", alors une couche de service est nécessaire.
Je sais que ce fil est ancien, mais une chose utile que j'ai faite dans la couche Service est de gérer les transactions (la couche entreprise ne devrait pas avoir besoin de savoir comment gérer les annulations, l'ordre des opérations, etc.).
Une autre chose que j'ai faite est de l'utiliser pour traduire entre les entités de domaine et les DTO. La couche métier traite du modèle de domaine, mais j'ai renvoyé les données à la couche de présentation sous forme de DTO (dans certains cas, il n'était pas pratique d'exposer l'ensemble du modèle de domaine à la couche de présentation pour diverses raisons), de sorte que la couche service gère ce mappage.
En fin de compte, je vois la couche métier comme plus fine, tandis que la couche Service peut être plus grossière en ce sens qu'elle pourrait appeler plusieurs opérations dans le BLL et ordonner des appels dans un seul appel de service.
Oui, et je voudrais également noter que la couche de service est un bon endroit pour l'authentification, basée sur les rôles et sur les utilisateurs.