Service- Schicht

[MQue]

Hallo,

ich bin mir nicht ganz sicher wann man eine Service- Schicht in einer Applikation einbaut und was der Unterschied zwischen der Service- Schicht und der DAO- Schicht sein soll,
Auch im Buch "Spring in Action 2.0" wird immer eine Service- Schicht über der DAO- Schicht eingezogen,
lg

 

[The_S]

Was hast du denn für ein Programm und wie schaut dein Design aus? Service-Schicht ist dann meistens WebService oder EJB, also die Schnittstelle nach außen, während DAOs intern für den Zugriff auf die Datenbank zuständig sind. In DAOs sollte keine Programmlogik stehen, diese wird dann in die Service-Schicht ausgelagert bzw. in eine Schicht zwischen Service und DAO (dann ist ein DAO nur für die Datenerzeugung zuständig und ein Service nur für die Bereitstellung der verarbeiteten Daten nach außen).

 

[ARadauer]

Die Service Schicht ist meiner Meinung nach allgemeiner als die DAO Schicht.
Zum Beispiel beim Absenden einer Bestellung: Die Service Schicht legt den Kunden an, speichert die Bestell Postitionen und erstellt die Bestellung an sich. Das sind mehrere Datenzugriffe für die sie vermutlich mehrer DAOs benötigt. Die Service Schicht kapselt diesen ganzen Ablauf als Service.

Natürlich kann es nun passieren, dass dieser Ablauf sehr simpel ist bz Kunden speichern. Be mir kommt es oft vor, dass die Service Schicht einfach nur eine Methode des DAOs aufruf... Bei sehr kleinen Anwendungen, lass ich dann oft die Service Schicht weg und benutze direkt das Dao. In diesem Fall entspricht dann das DAO dem Service....

Es kommt immer auf den Anwendungfall und die komplexität der Anwendung an, wie viele Schichten man braucht...

 

[MQue]

OK, so weit ich das jetzt verstanden habe, kann ein Service mehrere DAOs verwenden und ist daher eine Abstraktion der DAOs, damit bin ich allgemeiner in den Services,

@Aradauer
deine Sicht von Services wäre dann eine Sicht, wie man grundsätzlich auf Daten in einer Webanwendung zugreift und die Sicht von

@The_S
wäre dann die Sicht, wie man Daten einer Applikation von außen sieht (wie z.B.: WebServices, RPC, RMI) o.ä.

Hab ich das so richtig verstanden?

lg

PS: gibt es vielleicht ein Buch, indem man nachlesen kann, wie man die Architektur einer (Web-) Anwendung macht, mir ist klar, dass man mindestens ein MVC machen soll aber das mit den Services und DAOs führt ja dann doch ein bisschen weiter als das simple MVC.

 

[Noctarius]

Ich würde die Service-Schicht als Kombination aus den beiden vorherigen Aussagen umschreiben.

Ein Service ist eine in sich geschlossene Kapsellung von Services. Diese sind normalerweise wie von The_S beschrieben als EJB oder WebService oder auch einfach intern als OSGi Services verfügbar. Können aber auch nur Bundle (oder Application) intern existieren und z.B. über ein Interface beschrieben sein und durch eine entsprechende Implementierung implementiert werden.

In dieser Beschreibung sind auch DAOs Service-Schichten, aber eine so bestimmte, dass diese Schicht einen zusätzlichen, expliziten Namen bekommen hat um eine saubere Abtrennung zu erhalten.

Prinzipiell kapselt also eine Service-Schicht Logik (intern) von Zugriff (extern).

Auf ein Auto übertragen ist das Gaspedal der externe Zugriff, der Motor, wie auch immer er seine Antriebskraft entwickelt (Strom, Benzin, Fusion, ...) die interne Implementierung die mich beim Fahren nicht interessiert und das Benzinzuleitsystem bzw. das Einspritzsystem das DAO (Was eben in diesem Fall statt Daten Kraftstoff zur Verfügung stellt).

So habe ich die Möglichkeit zu Fahren hinter dem Service mit der Implementierung versteckt.

edit:
Bücher sollte es genug dazu geben, da es sich um normale Design Pattern handelt.

Darf ich denn mal fragen was du in der Firma machst? Bist du Auszubildender oder hat man dich in den Bereich Java "reingezwängt"?

 

[The_S]

OK, so weit ich das jetzt verstanden habe, kann ein Service mehrere DAOs verwenden

Jap. Bspw. hast du einen "Anmelde-Service". Dieser sorgt dann dafür, dass intern die Anmeldedaten nicht nur in die User-Tabelle geschrieben werden (Aufruf einer Methode des "UserDAO"), sondern dass bspw. die E-Mail Adresse auch auf Wunsch (Programmlogik: Kästchen in der Weboberfläche ist angehakt) in die Newsletter-Tabelle eingetragen wird (Aufruf einer Methode des "NewsletterDAO").

@Aradauer
deine Sicht von Services wäre dann eine Sicht, wie man grundsätzlich auf Daten in einer Webanwendung zugreift und die Sicht von

@The_S
wäre dann die Sicht, wie man Daten einer Applikation von außen sieht (wie z.B.: WebServices, RPC, RMI) o.ä.

Hab ich das so richtig verstanden?

Wir meinen eigentlich beide das Selbe . "Außen" kann bei mir bspw. auch eine Weboberfläche sein, an dieser Stelle wird lediglich das Backend verlassen (Eine EJB muss ja auch nicht Remote sein, sondern kann genauso gut auch nur Lokal verfügbar sein). Genauso kann bei ARadauer auch die Bestellung über bspw. eine Swing-Oberfläche abgesendet werden.

 

[MQue]

Darf ich denn mal fragen was du in der Firma machst? Bist du Auszubildender oder hat man dich in den Bereich Java "reingezwängt"?

Bin vor 3 Jahren in den Java- Bereich reingezwängt worden, hab aber viel Spass daran,
Ich vermute mal, Deine Frage kommt daher, da ich öfter (oft) Grundlegendes frage,
Das kommt vielleicht daher, dass ich am Anfang nur SPS- und Java- Desktop- Anwendungen programmiert habe und ich (bin in der Firma alleine für den Java- Bereich zuständig) für zweiteres mit den einfachen Mustern (MVC, Observer, Strategy, Composite, usw.) ausgekommen bin und die Firma seit einem Jahr jetzt in JavaEE entwickeln will.
Zusammengefasst bin ich sehr froh, in diesem Bereich gelandet zu sein, einige Sachen muss ich mir aber noch erarbeiten,
ich hoffe, meine Fragen werden trotzdem noch akzeptiert.
lg

 

[Noctarius]

Ja du hast die Frage gut erfasst War aber nicht bös gemeint, hatte mich nur grundlegend mal interessiert.
Bin auch eher per Zufall im bereich Java und vorallem im Bereich JEE gelandet aber es ist toll *gg* also immer schön brav weiter erarbeiten

 

[MQue]

Ja du hast die Frage gut erfasst War aber nicht bös gemeint, hatte mich nur grundlegend mal interessiert.
Bin auch eher per Zufall im bereich Java und vorallem im Bereich JEE gelandet aber es ist toll *gg* also immer schön brav weiter erarbeiten

Schreib zur Zeit gerade meine Diplomarbeit über das "Spring Framework", also deinen Vorsatz beherzige ich auf jeden Fall.

Beste Grüße,

 

[Gast2]

Kann eigentlich ein Service auch einen anderen Service aufrufen oder ist sowas eher unüblich und schlechtes Design?
Beschreibt ein Service immer eine Transaktion oder können auch mehrere Transaktionen in einem Service verwendet werden??? Oder teilt man diese dann wieder auf mehrere Service auf???

 

[maki]

Kann eigentlich ein Service auch einen anderen Service aufrufen oder ist sowas eher unüblich und schlechtes Design?
Beschreibt ein Service immer eine Transaktion oder können auch mehrere Transaktionen in einem Service verwendet werden??? Oder teilt man diese dann wieder auf mehrere Service auf???

Klar geht das, aber dann hoffe ich dass du deklaratives Transaktionsdefinition verwendest und darauf achtest, dass du die Services nicht gegenseitig zyklisch voneinander abhängig sind.

Zum Thema sauberes Design: Kommt immer darauf an. Manche sagen, das Services keine Logik enthalten dürfen, sondern nur an Domainklassen delegieren (DDD), aber der altgebackene Ansatz sieht dann so aus, dass die gesamte Logik in den Services steckt, dort DAOs verwendet werden und die Entites nur "doofe" JavaBeans sind ohne Logik.

 

[Gast2]

Klar geht das, aber dann hoffe ich dass du deklaratives Transaktionsdefinition verwendest und darauf achtest, dass du die Services nicht gegenseitig zyklisch voneinander abhängig sind.

Ähm hab jetzt kein Beispiel war einfach nur eine Verständnisfrage weil ich den Thread grad gelesen hab =). Was meinst du mit "zyklisch voneinander abhängig "?

Zum Thema sauberes Design: Kommt immer darauf an. Manche sagen, das Services keine Logik enthalten dürfen, sondern nur an Domainklassen delegieren (DDD), aber der altgebackene Ansatz sieht dann so aus, dass die gesamte Logik in den Services steckt, dort DAOs verwendet werden und die Entites nur "doofe" JavaBeans sind ohne Logik.

Die DAOs haben ja auch keine BusinessLogik oder? Holen mir meine Daten(Entites) von einer Datenquelle.

 

[maki]

Ähm hab jetzt kein Beispiel war einfach nur eine Verständnisfrage weil ich den Thread grad gelesen hab =). Was meinst du mit "zyklisch voneinander abhängig "?

ServiceA -> ServiceB -> ServiceC -> ServiceA
usw.

Die DAOs haben ja auch keine BusinessLogik oder?

Leider meist schon, schau mal in deine Abfragen ob du da eine Geschäftsregel erkennen kannst

 

[The_S]

Ähm hab jetzt kein Beispiel war einfach nur eine Verständnisfrage weil ich den Thread grad gelesen hab =). Was meinst du mit "zyklisch voneinander abhängig "?

Wenn Service1 auf Service2 zugreift, sollte Service2 nicht auch auf Service1 zugreifen. Bzw. ggf. auch über mehrere "Stationen".

Die DAOs haben ja auch keine BusinessLogik oder? Holen mir meine Daten(Entites) von einer Datenquelle.

Theoretisch: ja, praktisch: selten. Also bei uns haben wir ein Projekt mit 3 Schichten. Unterste Schicht is DAO. DAOs kennen untereinander nicht. oberste Schicht sind Services. Services kennen einander auch nicht und machen nichts weiter als eine Methode aus der mittleren Schicht aufzurufen. In der mittleren Schicht (Handler) steckt bei uns die Businesslogik. Handler kennen einander und kennen natürlich auch alle benötigten DAOs.

 

[Gast2]

zyklisch voneinander abhängig--> ok ist logisch dass dies nicht sein sollte =)...

Naja bei mir im Geschäft erkenn ich noch keine wirkliche saubere Schichtentrennung und keine Ahnung wer sich was dabei gedacht hat , darum schau ich mir des auch privat an und da ist die ganze Sache so groß, dass man von einem Projekt reden kann von dem her kann ich noch keine Geschäftlogik in den DAOs erkennen ^^...

Wie weit gehen für dich Geschäftsregel??? Was gehört für dich alles dazu z.B. wenn du einen join über mehrer Tabellen mit mehrern Parameter machst um deine entsprechenden Entities zu bekommen?