Sont les rôles d'un service et d'une façade semblable?

Question

Plus je lis, plus confus que je suis.

Notez que la question est liée à la façon dont le service et les façades ajustement sur le modèle MVC.

Ma compréhension est qu'une Façade n'est pas un super-objet dynamique, c'est simplement une manière d'exposer une interface simple/api pour effectuer une opération complexe (exemple: effectuer un 10$ de paiement, c'est une opération complexe qui implique un certain nombre d'opérations, mais une telle complexité peut être traité par une façade qui seront il suffit d'appeler le correspondant de l'objet dans un ordre particulier...etc...)

Maintenant, un service est un moyen de faire des appels à plusieurs DAOs afin d'obtenir des structures de données complexes (je ne suis pas trop sûr de cela, mais c'est ce que j'ai compris jusqu'à présent).

La Question est alors, quelle est la différence entre une façade et d'un service? À la fin de la journée, la façade peut parfaitement accéder à plusieurs DAOs afin d'effectuer une opération complexe, en fournissant une interface simple, et un service semble quelque chose de similaire.

Même chose arrive avec les transactions, je comprends qu'un service est l'endroit pour commencer les opérations, mais j'ai aussi l'impression qu'ils pourraient également être placés sur les façades, après tout, une façade peut appeler plusieurs DAOs trop.

Donc, qui mettent aurait plus de sens

contrôleur-façade-dao contrôleur de service de dao

ou peut-être

contrôleur-facadade-dao ET parfois contrôleur-façade-service-dao ??

Answer 1

Un service est une façon d'écrire une interface à un système externe, tel qu'un LDAP identité magasin, une passerelle de paiement ou d'une application à l'interface de gestion. C'est une manière conceptuelle de la recherche à l'extérieur du système en tant que fournisseur de services utiles peut-être avec interne des comportements plutôt que passif forfaitaire pour être opéré.

Une façade est une façon d'habillage de quoi que ce soit (y compris un service) pour présenter joliment à un autre composant. Les façades sont souvent utilisés lorsque:

• Une bibliothèque ou d'un composant est complexe et les besoins de votre application uniquement un sous-ensemble. Votre Façade présente la procédure simplifiée de l'API de l'application
• Vous êtes à l'aide de plusieurs bibliothèques ou les composants et la nécessité de les unifier, de présenter un consolidés de l'API de l'application
• La bibliothèque que vous utilisez a un complexe d'installation ou d'un ensemble de dépendances, et la façade encapsule tout ce qui dans le contexte de votre application.

Le peu qui est vraiment déroutant, c'est que vous pouvez (et même souvent) de créer une façade de plus de un ou de plusieurs services. Le service est de cette manière que l'élément accède à la ressource, et la façade est le bit qui simplifie le composant (tels que la configuration des options de connexion, etc).

Si vous écrivez votre propre DAO, vous n'aurez probablement créer votre service juste la façon dont vous avez besoin, de sorte que l'écriture d'une façade est une indication que vous avez fait mal. Si le DAO est réalisé par un tiers, et est plus complexe que vos besoins, alors vous pouvez façade le service.

Maintenant, un service est un moyen de faire des appels à plusieurs DAOs afin d'obtenir des structures de données complexes (je ne suis pas trop sûr de cela, mais c'est ce que j'ai compris 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:

• Au niveau de l'API:
  • DAO: accès précis aux propriétés
  • Service: Grossière de l'accès aux services
• Lorsque la mise en œuvre des mensonges:
  • DAO: Principalement sur le client, mais le stockage des données (sans comportement) dans la base de données
  • Service: Principalement sur le serveur
• La façon dont l'interface est appelée
  • DAO: Le client se lie directement à l'objet dans le même espace de noms et la JVM
  • Service: Le client est tout simplement un stub pour un réseau, de la croix-vm ou de la croix-espace de noms de l'opération

... la façade peut parfaitement accéder à plusieurs DAOs afin d'effectuer une opération complexe, en fournissant une interface simple, et un service semble quelque chose de similaire.

Une façade peut envelopper la couche DAO, mais je ne vois vraiment pas ce qui se passe dans une manière utile. Probablement vous avez besoin d'une API pour accéder aux propriétés des objets, parcourir le graphe d'objets et similaires, et c'est précisément ce que le DAO fournit.

Même chose arrive avec les transactions, je comprends qu'un service est le point de départ des opérations ...

Absolument, parce que l'opération est un service fourni par la base de données et sur un autre composant ou d'un système

... mais j'ai aussi l'impression qu'ils pourraient également être placés sur les façades, après tout, une façade peut appeler plusieurs DAOs trop.

Et à bien des égards le gestionnaire de transactions de service est une façade sur une beaucoup plus complexe backend de mise en œuvre, de la coordination de la transaction sur le web, application, base de données et de la transaction-connaissance des composants. Cependant c'est déjà disparaît par le service de transaction de mise en œuvre. Aussi loin que nous, les utilisateurs, sont concernés, il y a seulement l'interface publique.

C'est, en fait, le concept de ces modèles de conception - pour fournir juste la bonne quantité de l'API à l'utilisateur, en faisant abstraction de la complexité de la mise en œuvre derrière le mur de fer de l'interface du composant.

Donc, qui mettent aurait plus de sens

contrôleur-façade-dao contrôleur de service de dao

ou peut-être

contrôleur-facadade-dao ET parfois contrôleur-façade-service-dao ??

1. Le DAO est une sorte de service à la base de données, mais vraiment le DAO est un modèle de conception lui-même.
2. Si vous écrivez votre propre DAO, vous ne devriez jamais avoir besoin d'une façade.

C'est donc la bonne réponse est:

• contrôleur - dao

Answer 2

Littéralement, Façade, comme son nom l'indique signifie la face avant de l'immeuble. Les personnes passant à proximité de la route ne peut voir la façade, Ils ne connaissent rien au sujet de ce qu'à l'intérieur, le câblage, les tuyaux et autres complexités. La face cache toute la complexité de la construction et affiche un simple visage amical.

Dans logiciel conditions, façade se cache la complexité des composants logiciels, derrière, en fournissant une interface plus simple, n'a pas la fonctionnalité qui lui est propre et ne pas restreindre l'accès à la substsyem. Couramment utilisé dans la Conception Orientée Objet. De bons exemples sont SLF4J - C'est une api qui est une simple façade pour la connexion de systèmes permettant à l'utilisateur de brancher le système d'enregistrement souhaité au moment du déploiement.

Un service est une interface publique qui fournit l'accès à une unité de fonctionnalité et toujours écrites dans un cahier des charges. Il doit prendre en charge la communication des contrats (basé sur le message de la communication, des formats, des protocoles de sécurité, les exceptions, et ainsi de suite) ses différents consommateurs exigent. Il existe des services de processus d' - encapsulation de flux d'affaires , d'affaires de la logique de service - encapsulation de règles/les fonctions, les services de données à l'interaction avec les entités, les données de gestion des accès, des services d'infrastructured'utilité des fonctions telles que la surveillance, l'exploitation forestière et de sécurité. Les Services sont pour la plupart réutilisable, non associés, faiblement couplées, les unités de la fonctionnalité.

Ils sont beaucoup similaire, mais dépend de la façon dont vous le regardez.

La différence que je vois, les Façades sont conçues à l'intérieur. Vous regardez au sous-système et de la conception d'une façade de fournir un accès plus simple. Services sont conçus à l'extérieur dans. Vous regardez vos clients/clients de définir un le contrat et la conception du service.

Answer 3

Ma compréhension de la classique GoF Façade modèle est qu'il est principalement destiné à masquer une mauvaise conception. En règle générale, je dirais que l'on ne devrait avoir besoin que d'une Façade pour le code de legs.

Je pense aussi que ce modèle fait son chemin comme J2EE, base de modèle (Session de Façade), principalement en raison de l'EJB spec (au moins jusqu'à 2.x) intrinsèquement abouti à un service médiocre conception de la couche.

Donc, 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 avez besoin de masquer la complexité de code client, cela signifie généralement que vous avez réussi à fournir une bibliothèque, pas une couche de service; si, dans ce cas, la Façade devient réellement votre couche de service.

Sur l'autre main (en supposant que vous avez une bonne couche domaine), si vous avez vraiment besoin de fournir l'option de frai de flux complexe avec un seul appel de méthode (quelque chose ressemblant à des macros/aliases), ce qui doit en principe être mieux placé dans la couche d'application et non pas dans votre domaine de base -- avis que j'ai basculé la superposition de la terminologie de domain driven design, où il n'y a pas "d'accès aux données" ou "service" de la couche, mais "application", "domaine", "infrastructure".

Answer 4

Habituellement, ces termes sont utilisés uniquement dans leurs contextes spécifiques.

• 'Façade' usage courant contexte: API simple pour les pièces complexes de l'application (comme tiers libs)

• "Services" contexte: déverrouiller et de surface, et les entités commerciales dans le système. (SOA, DAO, de Sécurité, etc)

Vous pouvez afficher des modèles comme une langue qui évolue. Il ne semblait jamais être parfait, fin, chaque modèle a sa propre histoire et le contexte. Parfois, les classes peuvent être considérés comme des Services et des Façades en même temps, parfois pas.

Par exemple: l'appel de la troisième partie de l'API par le terme "Service" peut être considéré comme une mauvaise utilisation, en raison du mauvais contexte.

Answer 5

Un service d'interface représente généralement des préoccupations des entreprises: d'effectuer une opération(s) et/ou obtenir des informations. Il n'est pas déraisonnable pour le fournisseur de services pour mettre en œuvre leur service qu'une façade interne services de back-end - que vous n'auriez jamais le voir.

Votre façade peut envelopper certaines interfaces, qui peut comprendre l'interface de service(s).

Par exemple, vous pourriez avoir l'interface de service pour un compte de banque (fonctionnement: Banque transferts d'argent), et une API pour votre local enregistrements comptables (je transférer de l'argent). Vous pouvez introduire une façade avec un "transfert d'argent" opération qui utilise la banque de l'interface de service et de la gestion de votre local chéquier ainsi.