So schreiben Sie die Javaweb-Business-Schicht

Geschäftsschicht

Dienstschicht: Referenzieren Sie den entsprechenden Dao-Datenbankvorgang, in den Sie den benötigten Code schreiben können (z. B. einfache Beurteilung).

Die Serviceschicht ruft verschiedene Dao-Geschäftsvorgänge auf, wenn Sie beispielsweise ein Unternehmen haben, das hinzugefügt und dann geändert wird. Dann rufen Sie die Add- und Modifizierungsvorgänge von Dao auf, einschließlich einiger Datenkonvertierungen und logischer Beurteilungen in der Serviceschicht. Dao ist nur ein einfaches Hinzufügen, Löschen, Ändern und Abfragen. Und Transaktionen werden im Allgemeinen in der Serviceschicht platziert.
Da sowohl die Service-Schicht als auch die DAO-Schicht auf der Datenbank arbeiten können, sind die spezifischen Unterschiede:

Dao und Service entsprechen

Im Allgemeinen betreibt Hibernate DAO nur ein POJO-Objekt, sodass ein DAO einem POJO-Objekt entspricht. Die Serviceschicht dient der Transaktionsverwaltung (deklarative Transaktionsverwaltung) bei der Verarbeitung mehrerer POJO-Objekte (d. h. Datenoperationen für mehrere Tabellen). Der Serviceschicht (der Implementierungsklasse ihrer Schnittstelle) werden mehrere DAO-Objekte injiziert, um ihre Datenoperationen abzuschließen.

Das Vorhandensein oder Fehlen von Service
Meine Meinung zu diesem Punkt ist möglicherweise nicht korrekt. Meiner Meinung nach gibt es zwei Modi für den Aufbau der Geschäftsschicht:
Modus 1 ist Service + DAO, das heißt, DAO führt nur CRUD und ähnliche einfache Operationen durch (Funktionspunkte genannt) und umfasst keine Geschäftslogik durch Aufrufen eines oder mehrerer Funktionspunkte Anzahl sollte durch das Funktionsmodul bestimmt werden.
In diesem Modell wird die Geschäftslogik im Dienst platziert, und die Grenzen der Transaktion sollten auch im Dienst gesteuert werden. Natürlich führt die direkte Steuerung von Transaktionen im Dienst nicht-geschäftlichen Logikcode ein AOP kann dieses Problem lösen, dies ist auch einer der Gründe für die Einführung von Spring
Wenn wir über die Mängel sprechen, ist es, dass die Operationen an einigen Objekten einfach CRUD sind und die Serviceschicht umständlich erscheint >

Modus 2 ist Service + BO und BO = DAO + Geschäftsmethode. Fügen Sie Geschäftsmethoden basierend auf dem ursprünglichen DAO hinzu, um ein BO-Objekt zu bilden. Es ist zu beachten, dass Geschäftsmethoden in BO häufig auf ein Entitätsobjekt ausgerichtet sind. Wenn sie mehrere Entitätsobjekte umfassen müssen, sollte die Methode im Dienst platziert werden.

Zum Beispiel

Ein einfaches Bankkontoverwaltungssystem erstellt ein Konto-BO-Objekt, das Passwortänderungen enthalten kann Geld und andere Geschäftsmethoden (es ist nicht schwer zu erkennen, dass diese Methoden nur für ein einzelnes Kontoobjekt funktionieren). Jetzt müssen wir eine Übertragungsmethode hinzufügen, die im Dienst platziert werden soll.

Welche Beziehung besteht hier zwischen Service und BO? Ein weiteres Beispiel:

Nehmen wir als Beispiel die nationalen Verwaltungsbehörden: Das Getreideamt ist für die Getreidesammlung, den Verkauf von Saatgut usw. verantwortlich, und das Bauministerium ist für die Genehmigung von Landverkäufen und den Bau von Straßen zuständig usw. Dies sind alles Angelegenheiten innerhalb der Verwaltungsabteilung Sohn. Plötzlich kommt es an einem bestimmten Ort zu einer Überschwemmung. Während der Katastrophenhilfe muss das Getreideamt ein Lager eröffnen, um Getreide freizugeben, und das Bauministerium baut provisorische Häuser. Es ist notwendig, ein spezielles Katastrophenhilfekomitee einzurichten, das die Ressourcen der beiden Teile zuteilen wird. Die beiden Teile hier sind BO und das Katastrophenhilfekomitee ist Service. Ich weiß nicht, ob ich meine Meinung richtig ausgedrückt habe, haha. Modus 1 hat klare Grenzen bei der Trennung von Service und DAO, bringt jedoch unnötigen Code mit sich. Die Partitionierung von Modus 2 ist relativ komplex, kann jedoch die Codierungseffizienz verbessern.

Natürlich ist es in kleinen Anwendungen akzeptabel, DAO oder BO ohne Service zu verwenden.

Ob es Schnittstellen zwischen Service und DAO gibt

Die Schnittstelle ist ein Vertrag, der mehrere Implementierungen haben kann. Daher hängt das Vorhandensein oder Fehlen von Schnittstellen davon ab, ob die spezifische Implementierung diversifiziert werden muss. Wenn festgestellt wird, dass es nur eine Implementierung eines DAO oder eines Dienstes gibt, hat die Abstraktion der Schnittstelle wenig Sinn. Einige große Anwendungen erfordern jedoch möglicherweise mehrere Implementierungen von DAO und Service (z. B. das Konto-DAO im obigen Beispiel, das möglicherweise eine Hibernate-Implementierung, eine CMP-Implementierung und eine JDO-Implementierung erfordert, um die spezifische Implementierungsklasse vor dem zu verbergen). Auf der oberen Ebene müssen Sie Schnittstellen verwenden.

Den Erstellungsprozess bestimmter Implementierungsklassen ausblenden. Es gibt zwei Methoden: Eine davon ist die praktische Factory-Methode, die mit einer großen Codemenge verbunden ist (eine Factory für jedes DAO und jeden Dienst). Der zweite besteht darin, das IoC von Spring zu verwenden, um die Abhängigkeitsinjektion zu implementieren, ohne zusätzlichen Code zu schreiben. Dies ist auch der zweite Grund für die Einführung von Spring.

Das obige ist der detaillierte Inhalt vonSo schreiben Sie die Javaweb-Business-Schicht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!