Couche de Service vs couche D'affaires dans l'architecture des applications web?
je sais que cela peut sembler idiot, mais j'ai du mal à comprendre le besoin d'une couche service et ses différences avec la couche affaires.
donc, nous utilisons asp.net mvc 2 et ont la couche D'accès aux données qui fait tout le questionnement avec la base de données et puis nous avons la couche D'affaires qui a la logique d'affaires et les validations nécessaires pour être fait. Enfin, nous avons la couche de présentation qui contient essentiellement toutes les vues. En outre, nous avons également quelques assistants, DTOs et les classes viewmodel dans différents dossiers font partie 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 service est quelque chose qui appelle toutes les fonctions. Mais je ne peux pas vraiment voir le besoin de couche de Service dans notre application ? Ou il est peut-être déjà là et je ne le vois pas... Est-ce que quelqu'un peut expliquer avec un exemple comment une couche service est importante ? Comment c'est différent d'une couche affaires parce que de ce que j'ai lu semblent assez semblables? Si son dans le premier nécessaires à tous ? Tout ce que nous essayons de faire est de concevoir notre application de la meilleure façon possible, quelles sont vos pensées et votre expérience à ce sujet ?
9 réponses
il s'agit de découpler votre application en morceaux autonomes, chacun défini par l'exigence de faire un travail vraiment bien.
cela vous permet d'appliquer des modèles de conception spécialisés et les meilleures pratiques à chaque composant.
Par exemple, la couche de travail est de mettre en œuvre la logique métier. L'arrêt complet. L'exposition d'un IPA conçu pour être consommé par la couche de présentation n'est pas son "problème".
ce rôle de l'aller entre est mieux effectuée par une couche de service. Factoriser cette couche spécialisée vous permet d'appliquer des motifs beaucoup plus spécialisés à chaque composant individuel.
il n'y a pas besoin de faire les choses de conception de cette façon, mais l'expérience accumulée de la communauté indique qu'il résulte en une application qui est beaucoup plus facile à développer et à maintenir parce que vous savez exactement ce que chaque composant est censé faire, même avant de commencer à coder App.
Chaque couche doit faire un travail vraiment bien. Le rôle de go between que joue la couche service est un tel 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 manipuler ce rôle avec la logique d'affaires où il n'appartient pas. Pensez à la couche de service comme à une composante de cartographie. Elle est externe à la logique opérationnelle et ne appartiennent dans ses classes, ou dans les contrôleurs.
en outre, en raison de la prise en compte de la logique d'affaires, vous obtenez des objets d'affaires plus simples qui sont plus faciles à utiliser par d'autres applications et services que le "commerce" consomme.
ASP.NET MVC n'est rien d'autre qu'une plateforme pour vous permettre d'écrire vos applications en tant que composants spécialisés.
en raison de cette compréhension accrue de la façon de se spécialiser dans les composantes, les programmes primordiale bol de soupe et spaghetti en quelque chose de différent et étrange. La complexité à laquelle ils peuvent faire face, tout en utilisant des structures simples, s'accroît. L'évolution est. Si la vie est quelque chose à passer, cela doit être bon, donc garder la balle.
Vous pouvez trouver le terme Astronaute De L'Architecture intéressant.
le fait est, ne vous laissez pas piéger par toutes ces "couches" dont les gens bandent. Chaque fois que vous avez eu une autre couche à l'application, il doit y avoir un but en elle.
par exemple, certaines personnes ont réussi à combiner les concepts D'accès aux données et de couche de logique opérationnelle en un seul. Ce n'est pas bon pour toutes les solutions, mais ça marche parfaitement pour beaucoup d'entre elles. Certaines personnes peut même combiner la Présentation avec les Entreprises... ce qui est un non majeur dans beaucoup de cercles mais, encore une fois, peut être parfait pour le besoin en question.
fondamentalement, le problème que vous résolvez devrait dicter la structure de l'application. Si d'autres applications doivent s'intégrer à la vôtre, une couche Service peut être ajoutée. Cela pourrait prendre la forme de formulaires Web simples que d'autres peuvent afficher des données ou il pourrait aller plus loin pour être complet sur les services web. Il pourrait même être situations où vous voulez que la couche de service soit la principale Aller à l'emplacement pour les présentations multiples.
Vous pouvez obtenir d'aussi compliqué que vous voulez, mais une bonne règle de base est de garder les choses simples jusqu' les complications deviennent nécessaires.
Dans certains modèles, la couche de service n'est pas utilisé par la couche de présentation.
la couche service est appelée par d'autres applications qui veulent utiliser les couches business et data access dans l'application.
d'une certaine façon, la couche service est une autre couche frontale séparée de la couche présentation.
voir le schéma architectural ici. Les utilisateurs accèdent à l'application par la couche de présentation. Et l'externe les systèmes accèdent à l'application par la couche services. La couche présentation et la couche services traitent de la façade application dans la couche affaires.
à titre d'exemple de ce que ces autres "systèmes externes" pourraient être, les services web et les services de la FMC 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 s'assurer que les deux applications appliquent la même logique d'affaires, et que tout changement apporté à la logique d'entreprise sont reflétées dans les deux applications.
comme le fait remarquer Chris Lively, il ne faut pas se laisser emporter par la création de couches. Je recommande seulement de créer les couches qui seraient utiles dans votre demande. Dans mon expérience, la nécessité d'une couche de service n'est pas fréquent, mais le besoin d'une couche de gestion est très fréquent.
la couche de Service est habituellement construite en termes d'opérations discrètes qui doivent être prises en charge pour un client.
par exemple, une couche Service peut exposer la création d'un compte. Alors que la couche affaires peut consister à valider les paramètres nécessaires à la création d'un compte, à construire des objets de données à persister, etc.
souvent, la couche de Service utilise un code de Style procédural ou de Script de Transaction pour orchestrer l'entreprise et / ou la logique couche.
Sachant cela, vous pouvez comprendre que Couche Affairesvraiment une Couche de Service. À un moment donné, le point à partir duquel vous posez cette question étant un tel point, la distinction est essentiellement sémantique.
de mon point de vue, une couche service vous permet d'isoler votre couche présentation de votre couche affaires, de la même manière que la couche affaires et accès aux données vous isole de la façon dont vous persistez les données.
à l'intérieur de votre couche d'affaires, vous mettriez des choses qui sont essentielles à votre "entreprise". Artificiel (et probablement mal conçue exemple) serait que le lieu où dire l'actualisation des prix sur un produit se produire.
la couche service vous permet de plus de séparer l'interface de l'entreprise. Ou même échanger d'autres couches d'affaires selon les scénarios changeants de l'entreprise.
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.
Regardez ce que Randy Stafford dit au sujet de la couche de Service dans le livre "P of EAA" http://martinfowler.com/eaaCatalog/serviceLayer.html
une couche de Service définit limites de la demande [Cockburn PloP] et son ensemble d'opérations disponibles du point de vue de l'interface couches client. encapsule les logique d'entreprise de l'application, le contrôle des transactions et la coordination des réactions en la mise en œuvre de ses activités.
Simple. Pour exposer votre logique d'entreprise à un client, utilisez une couche de service. Demandez-vous:
lors de la modification de la logique opérationnelle, la couche de service devrait-elle changer? Si la réponse est "pas toujours", puis 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 affaires ne devrait pas avoir besoin de savoir comment gérer les retours en arrière, l'ordre des opérations, etc.).
une autre chose que j'ai faite est de l'utiliser pour traduire entre les entités du domaine et les DTOs. La couche Affaires traite du modèle de domaine, mais j'ai renvoyé les données à la couche présentation sous la forme de DTOs (dans certains cas, il n'était pas pratique d'exposer l'ensemble du domaine modèle à la couche de présentation pour diverses raisons), de sorte que la couche de service gère cette cartographie.
en fin de compte, je vois la couche affaires comme plus fine, alors que la couche Service peut être plus grossière en ce qu'elle pourrait appeler des opérations multiples dans le BLL, et commander des appels à l'intérieur d'un appel de service.
Oui, et je voudrais aussi noter que le service de la couche est un bon endroit pour l'authentification, à la fois en fonction des rôles et des utilisateurs.