java spring facade - Sind die Rollen einer Dienstleistung und einer Fassade ähnlich?




6 Answers

Ein Dienst ist eine Möglichkeit, eine Schnittstelle zu einem externen System zu schreiben, z. B. einen LDAP-Identitätsspeicher, ein Zahlungsgateway oder eine Anwendungsverwaltungsschnittstelle. Es ist eine konzeptuelle Art, das externe System als Anbieter nützlicher Dienste zu betrachten, vielleicht eher mit internen Verhaltensweisen als mit einem passiven Klumpen, an dem man operieren kann.

Eine Fassade ist eine Möglichkeit, alles (einschließlich eines Dienstes) einzubinden, um es einer anderen Komponente zu präsentieren. Fassaden werden oft verwendet, wenn:

  • Eine Bibliothek oder Komponente ist komplex und Ihre Anwendung benötigt nur eine Teilmenge davon. Ihre Fassade präsentiert der Anwendung die vereinfachte API
  • Sie verwenden mehrere Bibliotheken oder Komponenten und müssen diese vereinheitlichen, indem Sie der Anwendung eine konsolidierte API präsentieren
  • Die Bibliothek, die Sie verwenden, hat ein komplexes Setup oder eine Reihe von Abhängigkeiten, und die Fassade wickelt all das im Kontext Ihrer Anwendung ab.

Das Bit, das wirklich verwirrend ist, ist, dass Sie eine Fassade über einen oder mehrere Dienste erstellen können (und oft tun). Der Dienst ist der Weg, auf den die Komponente tatsächlich auf die Ressource zugreift, und die Fassade ist das Bit, das die Komponente vereinfacht (z. B. Konfiguration von Optionen, Verbindung usw.).

Wenn Sie Ihre eigene DAO schreiben, werden Sie wahrscheinlich Ihren Service genau so erstellen, wie Sie es benötigen. Eine Fassade zu schreiben, ist ein Hinweis darauf, dass Sie es falsch gemacht haben. Wenn das DAO von einem Dritten erstellt wird und komplexer als Ihre Anforderungen ist, können Sie den Dienst fasieren.

Ein Dienst ist nun eine Möglichkeit, Aufrufe an mehrere DAOs auszuführen, um komplexe Datenstrukturen zu erhalten (ich bin mir dessen nicht sicher, aber das ist, was ich bisher verstanden habe).

Ich würde sagen, dass das DAO ein eigenes Designmuster ist - siehe Wikipedia .

Wenn wir einen DAO mit einem Service vergleichen, haben wir:

  • API-Level:
    • DAO: Feinkörniger Zugang zu Immobilien
    • Service: Grobkörniger Zugang zu Diensten
  • Wo die Umsetzung liegt:
    • DAO: Hauptsächlich auf dem Client, aber Speichern von Daten (ohne Verhalten) in der Datenbank
    • Service: Hauptsächlich auf dem Server
  • Wie die Schnittstelle aufgerufen wird
    • DAO: Der Client bindet direkt an das Objekt in demselben Namespace und JVM
    • Service: Der Client ist einfach ein Stub für eine Netzwerk-, Cross-VM- oder Cross-Namespace-Operation

... die Fassade kann perfekt auf mehrere DAOs zugreifen, um eine komplexe Operation durch Bereitstellen einer einfachen Schnittstelle durchzuführen, und ein Dienst scheint zu etwas ähnlichem.

Eine Fassade könnte die DAO-Schicht einhüllen, aber ich sehe das nicht wirklich auf eine nützliche Weise. Wahrscheinlich benötigen Sie eine API, um auf die einzelnen Eigenschaften der Objekte zuzugreifen, den Objektgraphen und ähnliches zu durchlaufen, und genau das bietet das DAO.

Das gleiche passiert mit Transaktionen, ich verstehe, dass ein Service der Ort ist, um Transaktionen zu starten ...

Absolut, weil die Transaktion ein Service ist, der von der Datenbank und einer anderen Komponente oder einem System bereitgestellt wird

... aber ich glaube auch, dass sie auch an Fassaden angebracht werden könnten, schließlich kann eine Fassade auch mehrere DAOs aufrufen.

Und in vielerlei Hinsicht ist der Transaktionsmanager- Service eine Fassade für eine viel komplexere Backend-Implementierung, die die Transaktion im Web, in der Anwendung, in der Datenbank und in anderen transaktionsbewussten Komponenten koordiniert. Dies wird jedoch bereits durch die Implementierung des Transaktionsdienstes abstrahiert. Soweit wir als Benutzer betroffen sind, gibt es nur die öffentliche Schnittstelle.

Dies ist in der Tat der konzeptuelle Punkt dieser Entwurfsmuster - um dem Benutzer genau die richtige Menge an API zur Verfügung zu stellen und die Komplexität der Implementierung hinter der Eisenwand der Komponentenschnittstelle zu abstrahieren.

Also welcher Stapel würde mehr Sinn machen

Controller-Fassade-DAO Controller-Service-DAO

oder vielleicht

Controller-facadade-dao UND manchmal Controller-Fassade-Service-dao ??

  1. Das DAO ist eine Art Service für die Datenbank, aber tatsächlich ist das DAO selbst ein Designmuster.
  2. Wenn Sie Ihre eigene DAO schreiben, sollten Sie niemals eine Fassade benötigen.

Daher lautet die richtige Antwort:

  • Controller - dao
pattern beispiel

Je mehr ich lese, desto verwirrter bin ich.

Beachten Sie, dass sich alle Fragen darauf beziehen, wie Service und Fassaden auf das MVC-Muster passen.

Mein Verständnis ist, dass eine Fassade nicht ein super-intelligentes Objekt ist, es ist einfach eine Möglichkeit, eine einfache Schnittstelle / api einer komplexen Operation auszusetzen (Beispiel: führe eine Zahlung von 10 $ durch, es ist eine komplexe Operation, die eine Anzahl von involviert Operationen, aber diese Komplexität kann durch eine Fassade gehandhabt werden, die das entsprechende Objekt in einer bestimmten Reihenfolge aufruft ... etc ...)

Ein Dienst ist nun eine Möglichkeit, Aufrufe an mehrere DAOs auszuführen, um komplexe Datenstrukturen zu erhalten (ich bin mir dessen nicht sicher, aber das ist, was ich bisher verstanden habe).

Die Frage ist dann, was ist der Unterschied zwischen einer Fassade und einem Service? Am Ende des Tages kann die Fassade perfekt auf mehrere DAOs zugreifen, um eine komplexe Operation durchzuführen, indem sie eine einfache Schnittstelle bereitstellt, und ein Dienst scheint zu ähnlichem zu funktionieren.

Das gleiche passiert mit Transaktionen, ich verstehe, dass ein Service der Ort ist, um Transaktionen zu starten, aber ich glaube auch, dass sie auch auf Fassaden platziert werden könnten, schließlich kann eine Fassade auch mehrere DAOs aufrufen.

Also welcher Stapel würde mehr Sinn machen

Controller-Fassade-DAO Controller-Service-DAO

oder vielleicht

Controller-facadade-dao UND manchmal Controller-Fassade-Service-dao ??




Mein Verständnis des klassischen GoF Fassadenmusters ist, dass es hauptsächlich ein schlechtes Design verbergen soll. Als Faustregel würde ich sagen, dass man nur eine Fassade für Legacy-Code benötigen sollte.

Ich denke auch, dass dieses Muster seinen Weg als J2EE-Kernmuster (Sitzungsfassade) fand, hauptsächlich weil die EJB-Spezifikation (mindestens bis zu 2.x) inhärent zu einem schlechten Service-Layer-Design führte.

Daher wäre meine Antwort auf Ihre Frage ja - eine Fassade ist tatsächlich ein Service, der beim ersten Mal nicht richtig umgesetzt wurde. Wenn Sie die Komplexität aus dem Client-Code ausblenden müssen, bedeutet das normalerweise, dass Sie nur eine Bibliothek und keine Service-Schicht bereitstellen konnten. In diesem Fall wird die Fassade tatsächlich zu Ihrer Service-Schicht.

Auf der anderen Seite (vorausgesetzt, Sie haben eine anständige Domain-Ebene), wenn Sie wirklich die Option, komplexe Abläufe mit einem einzigen Methodenaufruf (etwas ähnlich Makros / Aliase) erzeugen würde, wäre dies in der Regel besser in der Anwendungsschicht platziert und nicht in Ihrer Kerndomäne - beachten Sie, dass ich die Terminologie der Schichttechnik auf domänengestütztes Design umgestellt habe, bei dem es keine "Datenzugriffs-" oder "Dienst" -Schicht, sondern "Anwendung", "Domäne", "Infrastruktur" gibt .




Normalerweise werden diese Begriffe nur in ihren spezifischen Kontexten verwendet.

  • Allgemeiner Benutzungskontext 'Facade': einfache API für komplexe Teile der Anwendung (wie Third-Party-Bibliotheken)

  • Kontext 'Dienste': Entsperren und Oberfläche der Geschäftsentitäten im System. (SOA, DAO, Sicherheit, usw.)

Sie können Muster als eine sich entwickelnde Sprache betrachten. Es schien nie perfekt zu sein, jedes Muster hat seine eigene Geschichte und seinen eigenen Kontext. Manchmal können Klassen gleichzeitig als Dienste und Fassaden betrachtet werden, manchmal nicht.

Zum Beispiel könnte das Aufrufen der API eines Drittanbieters mit dem Begriff "Service" aufgrund des falschen Kontextes als Missbrauch gewertet werden.




Ja, Fassade und Service sind nicht völlig unabhängig. Und irgendwann implementieren wir Service Layer als Facade, so dass der Kunde sich nicht um viele Details des Services kümmern muss. Je einfacher der Aufruf / die Schnittstelle eines Dienstes ist, desto einfacher und einfacher ist der Client-Code.

Der Martin Fowler sagt ... A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations

So wird der Service Layer manchmal als Facade verwendet.

Ref




Bevor ich versuche zu antworten, lassen Sie mich etwas klarstellen: In Unternehmensanwendungen gibt es drei verschiedene Dinge - Fassade , Service-Schicht und Remote-Fassade .

Fassade - während das Subsystem (die Subsysteme) umhüllt wird, befindet sich die Objekt- und UI-Anwendung (MVC) in der Regel noch immer in demselben Prozess. Die Kommunikation erfolgt also in gewohnter OO-Manier: Methoden aufrufen, Eigenschaften lesen, den Ereignissen zuhören.

Service Layer - Wenn der Business-Logik-Layer ausgereift und zu komplex wird, damit der MVC direkt mit ihm interagieren kann, wird der Service-Layer zwischen ihnen platziert. Service Layer ist eine API, die MVC als Wrapper für die Geschäftslogik verwendet. Es ist nicht entfernt und es ist nicht erforderlich, DTO zu verwenden, da kein Kabel an der Kommunikation beteiligt ist.

Remote Facade - (einfach jeder Fernservice) Dies ist eine Mischung aus Facade und Service Layer. Remote Facade beginnt, wenn Sie eine Art Wrapper über das System (und wir nennen es Facade) als Verteilungsgrenze bereitstellen möchten. Einer der Gründe dafür kann sein, dass mehrere UI-Anwendungen (MVC) die gleiche Remote Facade verwenden.

-

Vergleiche:

Facade vs. Service Layer : Sie sind ähnlich, da beide Subsysteme umhüllen. Der Unterschied besteht darin, dass Service Layer stärker auf die Bedürfnisse der Benutzerschnittstelle (MVC) ausgerichtet ist und Funktionen bereitstellt, die das Arbeiten mit Geschäftslogik vereinfachen. Auf der anderen Seite legt Facade die Funktionalität offen, um die Geschäftslogik zu vereinfachen, vereinfacht jedoch nicht unbedingt die Kommunikation mit der UI-Anwendung (MVC).

Fassade vs. Remote Facade (Service?) : Definitiv anders, da Remote Facade DTOs als Kommunikationsnachrichten verwenden muss. Remote Facade benötigt eine Art Proxy, wenn Sie es weiterhin als reguläres Objekt (Eigenschaften, Ereignisse) verwenden möchten. aber der Proxy wird sowieso DTOs für das reale Objekt verwenden, zB Remote Facade.

-

Mögliche Flüsse:

controller-facade-dao - zweifelhaft, aber immer noch möglich. Die Fassade wird normalerweise nicht verwendet, um nur DAL zu umhüllen. Als Subsystem sollte es etwas reifer sein. Aber wenn die Fassade Teil der Geschäftslogik ist, dann ist dies möglich. Dennoch muss das Subsystem stärker betont werden. Für mich ist DAL-Verpackung nicht genug, um es Fassade zu nennen.

controller-service-dao - absolut möglich. Viele Remote-Dienste arbeiten direkt mit der Datenbank über DAL.

controller-facade-service-dao - vielleicht, wenn Sie Service als ein Subsystem behandeln.

Ich würde noch einen hinzufügen, der Sinn ergibt:

controller-service [layer]-facade (part of business)-subsystem (eg accounting, business on its own)-dao - Ich bin sicher, dass Sie das übersetzen können.

-

Denken Sie daran, dass der Service (oder die Remote-Fassade) überall im Fluss vorhanden sein kann. Das hängt nur von Ihren Vertriebsbedürfnissen ab.




Facade und Service Layer haben eine gewisse Ähnlichkeit, aber beide haben zwei unterschiedliche Bedeutungen. Lassen Sie mich das anhand eines einfachen Beispiels erklären.

Stellen Sie sich vor, wir werden gebeten, eine neue Geschäftsanwendung zu erstellen. Dies erfordert die Erstellung einer Check-in-Anwendung, jedoch mit höherwertigen Funktionen und Kundenkartenfunktionen.

Nehmen wir an, die Anwendung sollte Facebook- und Foursquare-Check-in-Funktionen unterstützen, wenn der Benutzer sie verwenden möchte. Diese Funktion wird dringend benötigt, da einige Benutzer zögern, mehrere Anwendungen zu verwenden, die dieselbe Funktion ausführen oder soziale Konnektivität beseitigen.

Um eine Highlevel-Idee zu erhalten, verweisen Sie bitte auf den folgenden Link https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing

Die oben genannte Check-in-API an der ABC-Fassade ist ein Beispiel für die Verwendung von Facade.

Es hat unsere Service-API und auch Facebook und Foursqure-Check-in-Funktionen basierend auf der Auswahl des Kunden. Facebook- und Foursqure-APIs können spezifische Implementierungen (SOAP, Restful, etc.) und Sicherheitsanforderungen (OAuth usw.) haben.

Befriedigen einer dieser APIs (facebook, foursqure) Anforderungen müssen verschiedene Aufgaben erfüllen. Dies sind verschiedene Subsysteme mit unserer Check-In-Anforderung.

Die simple Verwendung der Fassade besteht also darin, mehrere Teilsysteme zu befriedigen, die durch eine einfache Methode ausgelöst werden

Aber wenn wir unsere eigene API betrachten, die eine Check-in-API ist, die sich bei MngCheckinSvc befindet. Dies ist eine Service-Layer-API . Dies ist die API, die die Check-in-Anforderungen unserer Anwendung enthält. Dies ist die API, die öffentlichen Zugriff von Ihrem MngCheckinSvc zur Verfügung stellt, um die Check-in-Anforderung für die Anwendung zu erfüllen.

Dies wird ein komplexes inneres Verhalten haben, aber die meisten davon werden noch anwendungsspezifische Logikimplementierungen sein.

Diese API (MngCheckinSvc.checkin (....)) greift möglicherweise auf andere DAO-Gruppen, interne APIs, andere interne Dienste usw. zu, um den Händler-Check-in mit der Anwendung zu erfüllen.




Related