it-swarm.com.de

Wie wichtig ist es, eine Serviceschicht zu erstellen?

Ich habe angefangen, eine App in drei Ebenen (DAL, BL, UI) zu erstellen [sie verwaltet hauptsächlich CRM, einige Verkaufsberichte und Inventar].

Ein Kollege sagte mir, dass ich zum Service-Layer-Muster wechseln muss, dass Entwickler aus ihrer Erfahrung zum Service-Muster gekommen sind und dass dies der bessere Ansatz für das Design der meisten Anwendungen ist. Er sagte, es sei viel einfacher, die Anwendung in Zukunft auf diese Weise zu warten.

Persönlich habe ich das Gefühl, dass es die Dinge nur komplexer macht, und ich konnte keinen großen Nutzen daraus ziehen, der dies rechtfertigen würde.

Diese App verfügt über eine zusätzliche kleine Teil-Benutzeroberfläche, die einige (aber nur wenige) Funktionen der Desktop-Anwendung verwendet, sodass ich Code (aber nicht viel) dupliziert habe. Nur wegen einiger Codeduplikationen würde ich es nicht in serviceorientiert konvertieren, aber er sagte, ich sollte es trotzdem verwenden, weil es im Allgemeinen eine sehr gute Architektur ist. Warum sind Programmierer so leidenschaftlich für Services?

Ich habe versucht, darauf zu googeln, bin aber immer noch verwirrt und kann mich nicht entscheiden, was ich tun soll.

68
BornToCode

Martin Fowlers Buch "Patterns of Enterprise Architecture" besagt:

Die einfachere Frage ist wahrscheinlich, wann man sie nicht benutzt. Sie benötigen wahrscheinlich keine Service-Schicht, wenn die Geschäftslogik Ihrer Anwendung nur eine Art von Client enthält - beispielsweise eine Benutzeroberfläche - und die Anwendungsfallantworten nicht mehrere Transaktionsressourcen umfassen. [...]

Sobald Sie sich jedoch eine zweite Art von Client oder eine zweite Transaktionsressource in Use-Case-Antworten vorstellen, lohnt es sich, von Anfang an in einer Service-Schicht zu entwerfen.

Ein Service Layer bietet den Vorteil, dass er einen gemeinsamen Satz von Anwendungsvorgängen definiert, die verschiedenen Clients zur Verfügung stehen, und die Antwort in jedem Vorgang koordiniert. Wenn Sie eine Anwendung haben, die mehr als eine Art von Client hat, die ihre Geschäftslogik nutzt und komplexe Anwendungsfälle mit mehreren Transaktionsressourcen aufweist, ist es sinnvoll, eine Service-Schicht in verwaltete Transaktionen aufzunehmen.

Mit CRM, Vertrieb und Inventar wird es viele Anwendungsfälle vom Typ CRUD geben, von denen fast immer eine Eins-zu-Eins-Korrespondenz mit Service-Layer-Vorgängen besteht. Die Antworten zum Erstellen, Aktualisieren oder Löschen eines Domänenobjekts sollten durch Service-Layer-Vorgänge atomar koordiniert und abgewickelt werden.

Ein weiterer Vorteil einer Service-Schicht besteht darin, dass sie für den lokalen oder Remote-Aufruf oder für beides ausgelegt werden kann - und Ihnen die Flexibilität bietet, dies zu tun. Das Muster bildet die Grundlage für die gekapselte Implementierung der Geschäftslogik einer Anwendung und den konsistenten Aufruf dieser Logik durch verschiedene Clients. Dies bedeutet, dass Sie auch die Duplizierung von Code reduzieren/entfernen, da Ihre Clients dieselben gemeinsamen Dienste nutzen. Sie können möglicherweise auch die Wartungskosten senken. Wenn sich Ihre Geschäftslogik ändert, müssen Sie (im Allgemeinen) nur den Service und nicht jeden Client ändern.

Zusammenfassend ist es gut, eine Service-Schicht zu verwenden - mehr noch, ich denke, in Ihrem Beispiel haben Sie angegeben, da es so klingt, als hätten Sie mehrere Clients mit Geschäftslogik.

59
Deco

Hinzufügen einer Service-Schicht, da Sie die Idee bewertet und den besten Ansatz gefunden haben: gut

Hinzufügen einer Service-Schicht, weil das alle coolen Kids tun: schlecht

Wenn dein Bauch sagt, dass du keinen brauchst, dann mach keinen.

Eine der enttäuschendsten Entwicklungen in der Programmierwelt in den letzten 10 Jahren ist, dass sie sich ärgerlich an der Mode orientiert hat und die Leute Trends und Bandwaggons folgen, als wären sie die Schuhe dieser Saison. Fallen Sie nicht in diese Falle. Denn in der nächsten Staffel wird 'jeder' dir sagen, dass du es anders hätte gestalten sollen.

An einer Serviceschicht ist nichts Falsches oder Richtiges - es handelt sich um einen bestimmten Ansatz, dessen Eignung hinsichtlich seiner technischen Vorzüge für das jeweilige Projekt bewertet werden sollte. Fühlen Sie sich nicht gezwungen, die Meinung anderer durch Ihr eigenes Urteilsvermögen zu ersetzen.

35
GrandmasterB

Es gibt viele Faktoren, die bei der Entscheidung zur Erstellung einer Serviceschicht eine Rolle spielen. Ich habe in der Vergangenheit aus folgenden Gründen Service-Layer erstellt.

  1. Code, der von mehreren Clients wiederverwendet werden muss.
  2. Bibliotheken von Drittanbietern, für die wir nur begrenzte Lizenzen haben.
  3. Dritte, die einen Integrationspunkt in unser System benötigen.
  4. Zentralisierung doppelter Geschäftslogik.

Fall 1: Sie erstellen Basisfunktionen, die von einer Vielzahl verschiedener Clients verwendet werden müssen. Die Service-Schicht bietet Funktionen für verschiedene Clients, mit denen Sie Ihre bereitgestellten Funktionen sofort nutzen können.

Fall 2: Normalerweise hosten Sie Code im App-Bereich, verwenden jedoch eine Drittanbieter-Bibliothek, für die Sie nur eingeschränkte Lizenzen haben. In diesem Fall haben Sie eine Ressource, die Sie überall verwenden möchten, aber nur eine begrenzte Anzahl von ihnen. Wenn Sie es hinter einem Dienst hosten, kann Ihre gesamte Organisation es aus ihren Anwendungen nutzen, ohne für jedes einzelne Hosting eine Lizenz erwerben zu müssen.

Fall 3: Sie erstellen Funktionen, mit denen Dritte mit Ihnen kommunizieren können. In Ihrem Beispiel können Sie einen Inventarendpunkt einrichten, damit Anbieter Nachrichten über eingehende Produktlieferungen an Sie weiterleiten können.

Fall 4: Sie haben Ihren Code unternehmensweit analysiert und festgestellt, dass separate Teams dasselbe erstellt haben (nur geringfügig anders implementiert). Mit einer Service-Schicht können Sie die besten Ansätze auswählen und jetzt den Prozess in allen Teams gleich implementieren, indem Sie sie in den Service einladen. Ein weiterer Vorteil der Zentralisierung der Logik besteht darin, dass Fehler gefunden werden. Jetzt können Sie den Fix einmal bereitstellen und alle Clients profitieren gleichzeitig von dem Vorteil.

Abgesehen davon gibt es potenzielle Nachteile für eine Serviceschicht.

  1. Fügt die Systemkomplexität hinzu. Wo Sie zuvor nur eine Anwendung zum Debuggen hatten, haben Sie jetzt zwei. Produktionsprobleme erfordern die Überprüfung der Client-App-Einstellungen, der Service-App-Einstellungen oder der Kommunikationsprobleme zwischen ansonsten korrekt eingerichteten Client- und Server-Apps. Dies kann schwierig sein, wenn Sie es noch nie zuvor getan haben.
  2. Ein Punkt des Scheiterns. Wenn Sie einen Serviceausfall haben, sind alle Clients betroffen. Wenn Code nicht auf diese Weise bereitgestellt wird, kann das Risiko geringer sein (obwohl es Möglichkeiten gibt, dies zu mindern).
  3. Die Versionierung kann schwieriger sein. Wenn Sie eine App haben, die einen Dienst verwendet, der Schnittstellen bereitstellt, können Änderungen gleichzeitig zwischen den beiden vorgenommen werden. Wenn Sie jetzt mehrere Clients haben, müssen Sie verwalten, wer sich auf V1 befindet, wer sich auf V2 befindet, und das Entfernen von V1 koordinieren (sobald Sie wissen, dass alle auf V2 aktualisiert wurden).

Der Hauptpunkt ist, dass es nicht immer ein Knaller ist, Ihr System serviceorientiert zu machen. Nach meiner Erfahrung ist dies normalerweise eine gute Idee (ich neige dazu, Anwendungen auf diese Weise zu strukturieren), aber es ist keine automatische Entscheidung. Am Ende des Tages müssen Sie die Vor- und Nachteile abwägen und die Entscheidung treffen, die für Ihre Situation richtig ist.

22
Phil Patterson

Die meisten Service-Layer, die ich gesehen habe, sind völlig durcheinander. Services haben in der Regel viele verschiedene Methoden, 1500 LOC sind nicht selten. Die verschiedenen Methoden haben nichts gemeinsam, teilen jedoch Code. Dies führt zu hoch Kopplung , niedrig Kohäsion . Es verstößt auch gegen OCP , da Sie jedes Mal, wenn eine neue Operation erforderlich ist, den Code ändern müssen, anstatt die Codebasis zu erweitern. Eine gut aufgebaute Serviceschicht ist theoretisch möglich, aber ich habe sie in der Praxis nie gesehen.

CQRS löst diese Probleme und verhindert, dass Sie eine dieser prozeduralen Serviceebenen erstellen müssen.

6
Jeroen

Das Hinzufügen einer Schnittstelle (eine Serviceschicht ist eine Art Schnittstelle) benötigt Zeit. Ein guter braucht viel Zeit zum Entwerfen und Testen. Es ist sehr wichtig, es beim ersten Versuch richtig zu machen, da das spätere Ändern alle Clients zerstört. Bedenken Sie auch, dass Sie wahrscheinlich erst dann wissen, was in dieser Benutzeroberfläche enthalten sein muss, wenn Sie einen zweiten Client mit leicht unterschiedlichen Anforderungen haben. Die Wartung eines Dienstes ist an sich ein nie endendes Projekt.

Wenn Sie in den meisten Organisationen zu Ihrem Geschäftssponsor gehen und ihn fragen: "Möchten Sie, dass andere Abteilungen von diesem System, das wir mit Ihrem Budget entwickeln, profitieren (es wiederverwenden)?" sie werden dich auslachen. Lassen Sie es zuerst für Ihren Geschäftssponsor funktionieren, und beginnen Sie dann damit, diesen Code wiederzuverwenden (in der Freizeit Ihrer Abteilung).

Wenn Sie sicher wissen, dass die Funktionalität, die Sie heute schreiben, von mehreren verschiedenen Service-Clients wiederverwendet wird, sollten Sie vom ersten Tag an eine Service-Schicht entwerfen. Wenn Sie sich nicht sicher sind oder bereits viele Unbekannte im Projekt vorhanden sind, lassen Sie zunächst etwas Einfaches arbeiten und trennen Sie es später in Service und Client, wenn Sie Zeit und Budget haben. Es ist viel einfacher, die Serviceschnittstelle gleich beim ersten Versuch zu erhalten, wenn Sie mit einem funktionierenden System beginnen.

P.S. Wenn Sie in Java arbeiten, hat Joshua Bloch in seinem Buch Effective Java viele fantastische Tipps zur Benutzeroberfläche.

6
GlenPeterson

Ich stimme mit Ihnen ein. Es ist nicht erforderlich, eine weitere Ebene einzuschließen, wenn Sie eine einzelne Benutzeroberfläche verwenden.

DAL, BL und UI/Controller sind eine gute Kombination zum Entwerfen einer Anwendung. Wenn Sie eine einzelne Benutzeroberfläche verwenden möchten, müssen Sie keine zusätzliche Ebene vorbereiten. Das Einfügen einer weiteren Ebene in die Anwendung erhöht nur den Entwicklungsaufwand/die Entwicklungszeit.

Ein weiteres Schema besteht darin, mehrere Benutzeroberflächen in Ihrer Anwendung zu verwenden. In diesem Fall ist es gut, eine Service-Schicht für die Verarbeitung von Benutzeroberflächen zu haben.

Stapelüberlauf: Diskussion zum Service-Layer-Muster

2
Satish Pandey

Ich würde bestreiten, dass Ihr BL Ihre Serviceschicht ist. Ein zentraler Ort, an dem sich Ihre Geschäftslogik befindet. Dies sollte eine DLL) sein, die von allem verwendet werden kann, das diese Logik benötigt. Dann können Sie eine Web-API-Ebene darüber legen, wenn Ihre App unterschiedliche Benutzeroberflächen hat.

0
user441521