Les rôles d'un service et d'une façade sont-ils similaires?
Plus je lis, plus je suis confus.
Notez que toute la question est liée à la façon dont le service et les façades s'adaptent au modèle MVC.
Ma compréhension est qu'une façade n'est pas un objet super intelligent, c'est simplement un moyen d'exposer une interface/api simple pour effectuer une opération complexe (exemple: effectuer un paiement de 10 $, c'est une opération complexe qui implique un certain nombre de opérations, mais une telle complexité peut être gérée par une façade qui appellera simplement l'objet correspondant dans un ordre particulier ... etc ...)
Maintenant, un service est un moyen d'effectuer des appels à plusieurs DAO afin d'obtenir des structures de données complexes (je ne suis pas trop sûr de cela, mais c'est ce que je comprends jusqu'à présent).
La question est alors, quelle est la différence entre une façade et un service? En fin de compte, la façade peut parfaitement accéder à plusieurs DAO afin d'effectuer une opération complexe en fournissant une interface simple, et un service semble à quelque chose de similaire.
Il en va de même pour les transactions, je comprends qu'un service est le lieu pour commencer des transactions, mais je pense également qu'elles pourraient également être placées sur des façades, après tout, une façade peut également appeler plusieurs DAO.
Alors quelle pile aurait plus de sens
contrôleur-façade-dao contrôleur-service-dao
ou peut-être
contrôleur-façade-dao ET parfois contrôleur-façade-service-dao ??
Un service est un moyen d'écrire une interface sur un système externe, tel qu'un magasin d'identités LDAP, une passerelle de paiement ou une interface de gestion d'application. C'est une façon conceptuelle de considérer le système externe comme un fournisseur de services utiles, peut-être avec des comportements internes plutôt que comme un bloc passif à opérer.
Une façade est un moyen d'envelopper n'importe quoi (y compris un service) pour le présenter joliment à un autre composant. Les façades sont souvent utilisées lorsque:
- Une bibliothèque ou un composant est complexe et votre application n'en a besoin que d'un sous-ensemble. Your Facade présente l'API simplifiée à l'application
- Vous utilisez plusieurs bibliothèques ou composants et devez les unifier, en présentant une API consolidée à l'application
- La bibliothèque que vous utilisez a une configuration complexe ou un ensemble de dépendances, et la façade enveloppe tout cela dans le contexte de votre application.
Ce qui est vraiment déroutant, c'est que vous pouvez (et faites souvent) créer une façade sur un ou plusieurs services. Le service est la façon dont le composant accède réellement à la ressource, et la façade est le bit qui simplifie le composant (comme la configuration des options, la connexion, etc.).
Si vous écrivez votre propre DAO, vous créerez probablement votre service exactement comme vous en avez besoin, donc écrire une façade est une indication que vous l'avez mal fait. Si le DAO est construit par un tiers et est plus complexe que vos besoins, , alors vous pouvez façonner le service.
Maintenant, un service est un moyen d'effectuer des appels à plusieurs DAO afin d'obtenir des structures de données complexes (je ne suis pas trop sûr de cela, mais c'est ce que je comprends jusqu'à présent).
Je dirais que le DAO est un modèle de conception qui lui est propre - voir wikipedia .
Si nous comparons un DAO avec un service, nous avons:
- Niveau d'API:
- DAO: Accès fin aux propriétés
- Service: accès grossier aux services
- Où se situe la mise en œuvre:
- DAO: principalement sur le client, mais en stockant des données (sans comportement) dans la base de données
- Service: principalement sur le serveur
- Comment l'interface est invoquée
- DAO: le client se lie directement à l'objet dans le même espace de noms et JVM
- Service: le client est simplement un stub pour une opération réseau, cross-vm ou cross-namespace
... la façade peut parfaitement accéder à plusieurs DAO afin d'effectuer une opération complexe en fournissant une interface simple, et un service semble à quelque chose de similaire.
Une façade pourrait boucler la couche DAO, mais je ne vois pas vraiment cela se produire d'une manière utile. Très probablement, vous avez besoin d'une API pour accéder aux propriétés individuelles des objets, parcourir le graphe des objets et similaires, et c'est précisément ce que le DAO fournit.
Il en va de même pour les transactions, je comprends qu'un service est l'endroit idéal pour commencer des transactions ...
Absolument, car la transaction est un service fourni par la base de données et sur un autre composant ou système
... mais je pense également qu'ils pourraient également être placés sur des façades, après tout, une façade peut également appeler plusieurs DAO.
Et à bien des égards, le service de gestionnaire de transactions est une façade sur une implémentation backend beaucoup plus complexe, coordonnant la transaction sur le Web, l'application, la base de données et d'autres composants sensibles aux transactions. Cependant ceci est déjà résolu par l'implémentation du service de transaction. En ce qui nous concerne, l'utilisateur, il n'y a que l'interface publique.
C'est, en fait, le point conceptuel de ces modèles de conception - pour fournir la bonne quantité d'API à l'utilisateur, en résumant les complexités de la mise en œuvre derrière la paroi de fer de l'interface du composant.
Alors quelle pile aurait plus de sens
contrôleur-façade-dao contrôleur-service-dao
ou peut-être
contrôleur-façade-dao ET parfois contrôleur-façade-service-dao ??
- Le DAO est une sorte de service à la base de données, mais en réalité, le DAO est un modèle de conception lui-même.
- Si vous écrivez votre propre DAO, vous ne devriez jamais avoir besoin d'une façade.
Par conséquent, la bonne réponse est:
- contrôleur - dao
Littéralement, Façade comme son nom l'indique signifie la face avant du bâtiment. Les gens qui passent devant la route ne peuvent voir que la façade, ils ne savent rien de ce qu'il y a à l'intérieur, du câblage, des tuyaux et autres complexités. Le visage cache toutes les complexités du bâtiment et affiche un visage convivial plus simple.
En termes de logiciel, la façade cache la complexité des composants logiciels derrière elle en fournissant une interface plus simple, n'a pas la fonctionnalité qui lui est propre et ne restreint pas l'accès au sous-système . Couramment utilisé dans la conception orientée objet. SLF4J en est un bon exemple - Il s'agit d'une API qui est une simple façade pour les systèmes de journalisation permettant à l'utilisateur final de brancher le système de journalisation souhaité au moment du déploiement.
Un service est une interface publique qui donne accès à une unité de fonctionnalité et toujours écrite selon une spécification. Il doit prendre en charge les contrats de communication ( communication basée sur les messages, formats, protocoles, sécurité, exceptions, etc. ) dont ses différents consommateurs ont besoin. Il y a services de processus - encapsulation des workflows métier, service de logique métier - encapsulation des règles/fonctions, services de données - interaction avec les entités, accès aux données gestion, services d'infrastructure - fonctions utilitaires telles que la surveillance, la journalisation et la sécurité. Les services sont principalement des unités de fonctionnalité réutilisables, non associées et faiblement couplées.
Ils sont très similaires mais dépendent de la façon dont vous les voyez.
La différence que je vois, les façades sont conçues à l'envers. Vous examinez le sous-système et concevez une façade pour fournir un accès plus simple. Les services sont conçus à l'extérieur. Vous regardez votre/vos client (s) définir un contrat et concevoir le service.
FACADE est un modèle de conception qui résout le problème où il existe un besoin d'une interface unifiée pour de nombreuses interfaces dans un sous-système afin de définir une interface de niveau supérieur qui rend le sous-système plus facile à utiliser.
CEPENDANT, UN SERVICE donne accès à des ressources ou à un ensemble d'interfaces/d'objets et ne simplifie pas nécessairement un tel accès. Ainsi, vous pouvez utiliser le modèle de façade pour mieux concevoir votre service afin que vous puissiez enregistrer le client qui sait comment construire pour l'utiliser.
Ma compréhension du modèle de façade GoF classique est qu'il est principalement destiné à masquer un mauvais design. En règle générale, je dirais que l'on ne devrait avoir besoin que d'une façade pour le code hérité.
Je pense également que ce modèle a fait son chemin en tant que modèle de base J2EE (Session Facade) principalement parce que la spécification EJB (au moins jusqu'à 2.x) a intrinsèquement entraîné une mauvaise conception de la couche de service.
Par conséquent, ma réponse à votre question serait oui - une façade est en fait un service qui n'a pas été correctement mis en œuvre la première fois. Si vous devez masquer la complexité du code client, cela signifie généralement que vous avez uniquement réussi à fournir une bibliothèque, pas une couche de service; dans ce cas, la façade devient en fait votre couche de service.
D'un autre côté (en supposant que vous avez une couche de domaine décente), si vous devez vraiment fournir la possibilité de générer des flux complexes avec un seul appel de méthode (quelque chose ressemblant à des macros/alias), cela serait généralement mieux placé dans la couche application et pas dans votre domaine principal - notez que j'ai changé la terminologie de superposition en conception pilotée par domaine, où il n'y a pas de couche "accès aux données" ou "service", mais "application", "domaine", "infrastructure".
Avant d'essayer de répondre, permettez-moi de clarifier une chose: il y a trois choses distinctes dans les applications d'entreprise - Facade, Service Layer, et Remote Facade.
Facade - tout en enveloppant le (s) sous-système (s), est toujours un objet et l'application UI (MVC) vit généralement dans le même processus. Ainsi, la communication se fait de manière habituelle OO manière: appeler les méthodes, lire les propriétés, écouter les événements.
Service Layer - lorsque la couche logique métier devient mature et trop complexe pour que le MVC interagisse directement avec elle, alors la couche Service est placée entre elles. Service Layer est une API que MVC utilise comme wrapper de la logique métier. Il n'est pas distant et il n'est pas nécessaire d'utiliser le DTO car aucun fil n'est impliqué dans la communication.
Façade distantesimplement, tout service distant) il s'agit d'un hybride de la couche façade et service. La façade à distance commence à exister lorsque vous souhaitez exposer une sorte de wrapper sur le système (et nous l'appelons façade) en tant que limite de distribution. L'une des raisons peut être d'autoriser plusieurs applications UI (MVC) à utiliser la même façade distante.
-
--- (Comparaisons:
Facade vs. Service Layer: ils sont similaires car ils enveloppent tous les deux des sous-systèmes. La différence est que Service Layer est plus orienté sur les besoins des applications UI (MVC) et expose des fonctions pour simplifier le travail avec la logique métier. D'un autre côté, Facade expose des fonctionnalités pour simplifier la logique métier, mais ne simplifie pas nécessairement la communication avec l'application UI (MVC).
Facade vs. Remote Facade (Service?): définitivement différent puisque Remote Facade doit utiliser les DTO comme messages de communication. Remote Façade aura besoin d'une sorte de proxy si vous souhaitez toujours l'utiliser comme un objet normal (propriétés, événements); mais le proxy utilisera de toute façon les DTO vers l'objet réel, c'est-à-dire la façade distante.
-
Flux possibles:
controller-facade-dao - douteux, mais toujours possible. La façade n'est généralement pas utilisée pour envelopper uniquement DAL. Il devrait y avoir quelque chose de plus mature en plus en tant que sous-système. Mais, si la façade fait partie de la logique métier, alors oui, c'est possible. Encore faut-il mettre davantage l'accent sur le sous-système. Pour moi, l'emballage DAL ne suffit pas pour l'appeler Façade.
controller-service-dao - absolument possible. De nombreux services distants fonctionnent directement avec la base de données via DAL.
controller-facade-service-dao - peut-être, si vous traitez le service comme un sous-système.
J'ajouterais un autre qui peut avoir du sens:
controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao - Je suis sûr que vous pouvez traduire cela.
-
N'oubliez pas que le service (ou la façade à distance) peut exister n'importe où dans le flux. Cela est simplement dicté par vos besoins de distribution.
Oui, la façade et le service ne sont pas entièrement indépendants. Et quelque temps, nous implémentons la couche Service en tant que façade afin que le client ne soit pas dérangé par de nombreux détails du service. Plus l'appel/l'interface d'un service est simple, plus le code client est simple et facile.
Le Martin Fowler dit ...
Une couche de service définit la frontière 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ôle les transactions et coordonne les réponses dans la mise en œuvre de ses opérations
La couche services est donc parfois utilisée comme façade.
Habituellement, ces termes sont simplement utilisés dans leurs contextes spécifiques.
Contexte d'utilisation commun 'Facade': API simple pour des parties complexes de l'application (comme les bibliothèques tierces)
Contexte "Services": déverrouillez et faites apparaître les entités commerciales dans le système. (SOA, DAO, sécurité, etc.)
Vous pouvez afficher les modèles comme une langue qui évolue. Il n'a jamais semblé être parfait et chaque motif a sa propre histoire et son propre contexte. Parfois, les classes peuvent être considérées comme des services et des façades en même temps, parfois non.
Par exemple: appeler une API tierce par le terme "Service" pourrait être considéré comme une mauvaise utilisation, en raison du mauvais contexte.
La première chose à noter est qu'un modèle de conception est une description d'un problème (de conception) courant avec une solution standard. Dans certains cas, il existe plusieurs façons de résoudre le problème d'une manière qui convient à toutes les exigences (par exemple, les modèles Iterator et Singleton ont des tonnes d'implémentations différentes; par exemple, vérifiez le travail de Alexandrescu et comparez avec les solutions GoF standard) et dans certains cas, il existe différents modèles avec la même solution (code) (par exemple, comparer les diagrammes de classes des modèles Composite et Decorator dans le livre GoF).
Selon le GoF, l'objectif du modèle de façade est de (citation littérale):
Fournissez une interface unifiée à un ensemble d'interfaces dans un sous-système. La façade définit une interface de niveau supérieur qui facilite l'utilisation du sous-système.
Les services ont l'intention de fournir à un utilisateur une seule interface de niveau supérieur avec une fonctionnalité donnée. Cela n'en fait pas forcément une façade, car un service à proprement parler n'est pas par définition un unified interface to a set of interfaces in a subsystem.
Mais nous pouvons faire mieux que ça
Votre question était de savoir si les modèles sont "similaires". Si nous les considérons comme "similaires" lorsque le motif A est égal à B et le motif B est égal à A, alors nous devons répondre à 2 questions:
Question 1: est un Service un Facade? Un service doit certainement exposer des fonctionnalités et est certainement une interface unique qui expose ces fonctionnalités. La fonctionnalité est normalement décomposée en petits morceaux, donc oui, les services répondent aux exigences sous-jacentes d'une façade. En d'autres termes: face au problème d'exposer les interfaces sous-jacentes comme une interface "de service" unifiée, le motif de façade correspond aux exigences et est utilisé pour résoudre le problème de service. La réponse à cette question est oui.
Question 2: est un Facade un Service? Les services sont normalement conçus comme des unités de fonctionnalité réutilisables, non associées et faiblement couplées. La réflexion sur la communication entre les composants est importante pour les services, car ils reposent généralement sur une interface TCP/IP telle que SOAP ou WCF. Cela signifie également que les fonctionnalités sont souvent réécrites pour s'adapter à la services paradigme plus proche, qui ajoute une exigence implicite motivée par les performances pour le modèle. Les façades n'ont pas cette exigence supplémentaire. En d'autres termes: ne façade n'est pas un service =.
En termes exacts, ces concepts sont étroitement liés, mais pas les mêmes.
Mais nous pouvons faire mieux
Cette réflexion soulève la question de savoir si n service est une version étendue d'une façade? C'est si un service répond à toutes les exigences d'une façade et s'étend au-dessus de cela.
Si vous lisez attentivement la description du GoF, la réponse est oui, c'est-à-dire: si une condition est remplie: le service doit exposer les sous-systèmes. En réalité, je pense que cette condition se vérifie normalement, ou vous sur-concevez vos services - bien qu'à strictement parler, je suppose que ce n'est pas une restriction difficile.
Une interface service représente généralement des préoccupations commerciales: effectuez une ou plusieurs opérations et/ou obtenez des informations. Il ne serait pas déraisonnable pour le fournisseur de services d'implémenter son service comme une façade par rapport aux services principaux internes - vous ne verriez jamais cela.
Votre façade peut envelopper certaines interfaces générales, qui peuvent inclure des interfaces de service.
Par exemple, vous pouvez avoir une interface de service pour un compte bancaire (opération: virement bancaire) et une API locale dans vos documents comptables locaux (je transfère de l'argent). Vous pouvez introduire une façade avec une opération de "transfert d'argent" qui utilise l'interface de service de la banque et gère également votre chéquier local.
La façade et la couche de service a une sorte de similitude mais les deux ont deux sens distingués. Permettez-moi d'expliquer cela à l'aide d'un exemple simple.
Imaginez qu'on nous demande de créer une nouvelle application métier. Cela nécessite de créer une application d'enregistrement, mais avec plus de fonctionnalités à valeur ajoutée et de fonctionnalités de carte de fidélité.
Disons que l'application doit prendre en charge les fonctionnalités d'enregistrement Facebook et Foursquare si l'utilisateur souhaite l'utiliser. Cette fonctionnalité est très nécessaire parce que certains utilisateurs hésitent à utiliser plusieurs applications faisant la même fonction ou à se débarrasser de la connectivité sociale.
pour vous faire une idée de haut niveau, reportez-vous à l'exemple d'api sur le lien suivant https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing
L'API d'enregistrement située au-dessus de la façade ABC est un exemple d'utilisation de la façade.
Il a notre API de service et également des capacités d'enregistrement Facebook et Foursqure basées sur la sélection du client. Les API Facebook et Foursqure peuvent avoir des implémentations spécifiques (SOAP, Restful, etc.) et des exigences de sécurité (OAuth, etc.), etc.
Satisfaire à l'une des exigences de ces API (Facebook, Foursqure) doit remplir différents ensembles de tâches. ce seront différents sous-systèmes avec notre exigence d'enregistrement.
Donc, l'utilisation simpliste de la façade consiste à satisfaire plusieurs sous-systèmes déclenchés par une méthode simple
Mais si nous considérons notre propre API, qui est une API d'enregistrement située sur MngCheckinSvc. Il s'agit d'une API de couche de service . Il s'agit de l'API qui contient les exigences d'enregistrement de notre application. Il s'agit de l'API qui fournit un accès public à partir de votre MngCheckinSvc pour gérer les exigences d'enregistrement à l'application.
Cela aura des comportements internes complexes mais la plupart d'entre eux seront des implémentations logiques spécifiques à l'application.
Cette API (MngCheckinSvc.checkin (....)) peut accéder à différents ensembles de DAO, API internes, peut être d'autres services internes, etc. afin de remplir l'enregistrement du marchand avec dans l'application.
C'est le "contexte" qui compte. La façade et le service ne sont pas en conflit.
Tout d'abord, je n'ai jamais entendu parler de "Service" et "Facade" dans le contexte de MVC.
Lorsque les gens parlent de Service, il s'agit davantage d'un système ou d'un composant fournissant des actions significatives pour le monde extérieur. Vous pouvez parfois voir "Service" lié à "Unité de travail" (et donc, transaction).
Le service est également utilisé dans le cadre d'une approche de superposition d'application: nous avons Service au-dessus de DAO, pour lequel Service accédera aux données via DAO et la logique métier est placée dans la couche Service, quelque chose comme ça.
La façade est généralement utilisée dans le contexte d'un modèle de conception, et l'accent est mis sur "la dissimulation d'opérations compliquées et l'exposer comme une opération simple".
La façade peut être ou ne pas être un service (une opération dans la façade peut ne pas représenter une unité de travail, mais elle est toujours une façade valide), de même, un service peut ou non être une façade (un service ne peut pas cacher de complication mais c'est toujours un Service).
Encore une fois, c'est le "contexte" qui compte.
Par exemple, lorsque vous parlez de superposition d'application, il est tout simplement irrationnel de dire "XXX est une façade pour accéder à DAO". De même, si vous parlez d '"approche de conception", il est plus raisonnable de dire "XXX est une façade à plusieurs back-end" au lieu de l'appeler un "service" ici (bien que XXX soit en fait un service).