La Couche de Service vs Couche de gestion dans l'architecture des applications web?

Question

Je sais que cela peut paraître idiot, mais je trouve qu'il est difficile de comprendre la nécessité d'une couche de service et de ses différences avec la couche de gestion.

Nous sommes, donc, à l'aide de asp.net mvc 2 et ont Accès aux Données de la couche qui fait tout l'interrogation de la base de données et puis nous avons la Couche de gestion qui a la logique métier et les validations nécessaires à faire. Enfin, nous avons la Couche de Présentation qui, fondamentalement, a tous les points de vue. En outre, nous avons également des aides,les Dto et viewmodel classes dans différents dossiers, comme une partie de nos bibliothèques. Mais j'ai essayé de lire à propos de l'architecture, et il semble que la couche de service est un élément important de l'architecture.

Tout ce que je comprends, c'est qu'une couche de service est quelque chose qui fait appel à toutes les fonctions. Mais je ne vois pas vraiment la nécessité de la couche de Service dans notre application ? Ou il a peut-être déjà là et je ne le vois pas... quelqu'un Peut-il expliquer avec un exemple comment une couche de service est-elle importante ? Comment elle est différente de la couche de gestion en raison de ce que j'ai lu me semblent assez similaires? Si son dans le premier nécessaires à tous ? Tout ce que nous essayons de faire est d'architecte de notre application dans la meilleure façon possible, quels sont vos avis et votre expérience sur elle ?

Answer 1

Il est tout au sujet de découplage votre application en morceaux, chacun défini par l'obligation de faire un travail vraiment bien.

Ceci vous permet d'appliquer spécialisée dans la création de modèles et de pratiques exemplaires pour chaque composant.

Par exemple, la couche de travail est de mettre en œuvre la logique métier. L'arrêt complet. Exposer une API conçue pour être consommée par la couche de présentation n'est pas son "inquiétude".

Ce rôle de l'aller entre est mieux effectuée par une couche de service. L'affacturage cet spécialisé couche permet d'appliquer beaucoup plus spécialisé des modèles pour chaque composante.

Il n'est pas nécessaire de faire de la conception des 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 prévu de le faire, même avant de commencer le codage de l'application.

Chaque couche doit faire un travail vraiment bien. Le rôle de go entre la couche de service effectue en est un exemple bien défini d'emplois et c'est la raison de son existence: c'est une unité de la complexité qui est conçu de la même manière, encore et encore, plutôt que d'avoir à réinventer la roue à chaque fois, pour marquer ce rôle avec la logique métier où il n'appartient pas. Pensez à la couche de service en tant que composant de mappage. Elle est extérieure à la logique métier et ne fait pas partie de ses classes, ou dans les contrôleurs soit.

Aussi, à la suite d'être pris en compte de la logique métier, vous obtenez la plus simple des objets métiers qui sont plus faciles à utiliser par d'autres applications et services que les "affaires" en consomme.

ASP.NET MVC n'est rien si ce n'est une plate-forme pour vous permettre d'écrire vos applications en tant que composants spécialisés.

En conséquence de cette augmentation de la compréhension de la façon de se spécialiser composantes, évolution des programmes de l'primordiale bol de soupe et spaghetti en quelque chose de différent et étrange. La complexité qu'ils peuvent aborder, tout en utilisant des structures simples, est en augmentation. L'évolution est se passe. Si la vie est quelque chose aller près, ce doit être bon, donc garder le roulement de boule.

Answer 2

Vous trouverez peut-être la durée de l'Architecture de l'Astronaute intéressant.

Le point est, ne pas se laisser prendre à toutes ces "couches" que les gens échanger sur. Chaque fois que vous avez une autre couche de l'application, il doit être un but en elle.

Par exemple, certaines personnes ont réussi à combiner les concepts de l'Accès aux Données et de la couche Logique Métier dans un. Il n'est pas bon pour chaque solution, mais il fonctionne parfaitement pour beaucoup d'entre eux. Certaines personnes peuvent même combiner la Présentation avec les Entreprises... qui est un grand pas de no dans beaucoup de cercles, mais, encore une fois, peut-être parfait pour le besoin en question.

Fondamentalement, le problème à résoudre doit dicter la structure de l'application. Si d'autres applications ont besoin pour s'intégrer avec le vôtre, puis une Couche de Service peut être nécessaire d'ajouter. Cela peut prendre la forme de simples formulaires web et les autres utilisateurs peuvent publier des données ou il pourrait aller plus loin pour être complet sur les services web. Il pourrait même y avoir des situations où vous voulez que le service de la couche pour être le premier endroit pour aller à plusieurs présentations.

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.

Answer 3

Dans certains modèles, la couche de service n'est pas utilisé par la couche de présentation.

La couche de service est appelé par d'autres applications qui veulent utiliser le business et les couches d'accès aux données dans l'application.

Dans un sens, la couche de service est un autre avant la fin de l'séparé de la couche de présentation.

Voir le schéma architectural ici. Les utilisateurs accèdent à l'application à travers la couche de présentation. Et les systèmes externes d'accès à l'application par les services de la couche. La couche présentation et la couche de services en parler à l'application de la façade dans la couche de gestion.

Comme un exemple de ce que les autres "systèmes externes" peut-être, des services web et des services WCF appel de la couche de service. Certains autres applications web pourrait appeler cela de l'application de la couche de service dans un appel de service web. Ce serait une façon de s'assurer que les deux applications sont en appliquant la même logique d'entreprise, et que toutes les modifications apportées à la logique d'entreprise sont reflétées dans les deux applications.

Comme Chris Animé le souligne, il ne faut pas se laisser emporter par la création de couches. Je le recommande seulement de créer des couches qui serait utile dans votre application. 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.

Answer 4

La Couche de Service est généralement construite en termes d'opérations distinctes qui doivent être pris en charge pour un client.

Par exemple, une Couche de Service peut exposer la Création d'un Compte. Alors que la Couche de gestion peut consister à valider les paramètres nécessaires à la création d'un compte, la construction des objets de données pour être conservé, etc.

Souvent, la Couche de Service utilise une procédure de Transaction ou de Script code de style pour orchestrer l'activité et/ou de la logique des calques.

Sachant cela, vous pouvez comprendre que votre Couche de gestion est vraiment un Service à la Couche. À un certain point, le point à partir duquel vous vous posez cette question un tel point, la distinction est surtout sémantique.

Answer 5

De mon point de vue une couche de service vous permet d'isoler la couche de présentation de votre couche de gestion, de la même manière les affaires et la couche d'accès aux données vous isole du comment vous persister les données.

À l'intérieur de votre couche de gestion vous l'avais mis de 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 de service vous permet de mieux séparer l'interface de l'entreprise. Ou même d'échanger d'autres couches de gestion selon les scénarii d'évolution de l'entreprise.

Pas tous les besoins de l'application d'un bien (un lot de variables dans la détermination), trop architecture peut introduire de la complexité de votre équipe ne peut pas le besoin.