Einsatz von Spring

[MQue]

Hallo,

bin gerade dabei, mich in Spring einzuarbeiten,
Wie im unteren Bild ersichtlich habe ich 4 Packages, im service- Package befindet sich eine Klasse mit der main- Methode. Alle Klassenabhängigkeiten über Spring sind singleton.

Meine Frage wäre in Richtung Abhängigkeiten und wie oft man z.B.: DI (IoC) einsetzen soll.
Wenn zu viele Klassen über DI abhängig sind, kann es auch ziemlich unübersichtlich werden bzw. können gegenseitige Abhängigkeiten zum Absturz führen, oder ist das eher nicht möglich?

PS: natürlich sind nur einezelne Klassen der Packages über DI verbunden.

lg

 

[maki]

Für Eclipse gibt es die SPring IDE, die zeigt dir die abhängigkeiten u.a. auch grafisch, da sieht man unter Umständen seltsame Abhängigkeiten sehr schnell.

Die DI von Spring kann man im Prinzip immer einsetzen wenn man Objekte hat die abhängigkeiten auf andere Objekte haben.

Wie sieht den die (geplante?) Architektur des Systems aus?

 

[Noctarius]

Zur Frage wann und wo und wie oft man DI einsetzen darf / kann / soll würde ich pauschal antworten (ja Pauschalantworten sind pauschal immer doof ) so oft wie es geht und quasi überall. Schließlich weiß man nie was mal an Anforderungen kommt.

 

[byte]

Wenn zu viele Klassen über DI abhängig sind, kann es auch ziemlich unübersichtlich werden bzw. können gegenseitige Abhängigkeiten zum Absturz führen, oder ist das eher nicht möglich?

Wenn es zuviele Abhängigkeiten zwischen Klassen gibt, wird es immer unübersichtlich, völlig egal ob die Klassen per DI verdrahtet sind oder hart im Code. "Zum Absturz führen" kann sowas halt beim Starten der Anwendung, wenn es Zyklen bei der Initialisierung der Klassen gibt, der nicht irgendwie geregelt ist. Aber grade da bietet einem Spring DI gute Möglichkeiten, solche Zyklen aufzulösen. Das ist ohne DI deutlich frickliger und fehleranfälliger.

 

[MQue]

Wie sieht den die (geplante?) Architektur des Systems aus?

OK, ist nicht auf meinem Mist gewachsen:

Es gibt einen großen Service (Server), der folgende Arbeit verrichtet:

1. Konfigurations- XML- Datei einlesen
2. aus den Infos der XML- Datei die Tabellen (über hibernate) erstellen (eine Tabelle, in der die Werte drinn stehen, die in Punkt 4 vom Remote- Gerät empfangen wurden und es gibt eine weitere Tabelle, in der die Clients eingetragen sind, die zu einem Zeitpunkt verbunden sind und diese Clients haben über eine Verbindung zu den Variablen, die sie anzeigen wollen)
3. eine TCP- Verbindung zu einem Remote- Gerät aufbauen
4. die Werte, welche vom Remote- Geräte empfangen werden, anhand der eingelesenen XML- Datei aufbereiten und in die Datenbank schreiben.

---------------- das war der Service wie wir ihn nennen (bzw. Server)----------

5. ein Client verbindet sich (per Applikation oder per Browser o.ä.) mit dem Service
und trägt sich bei den Variablen ein, die er erhalten will

6. ger Client zeigt die Werte an

Das ist die Architektur welche wie gesagt nicht auf meinem Mist gewachsen ist.
Ich würde mal sagen, das sie einer 3 stufigen Architektur entspricht (Darstellung, Bussineslogik und Persistenzlogik)

Was haltet ihr davon?

Ich versteh schon, warum du (geplante?) schreibst, ich würde mir auch mehr Einsatz von UML, CASE o.ä. wünschen aber meine Vorgesetzen kennen sich da nicht aus.
Ich versuche trotdem so oft es geht UML einzusetzen und auch auf die Einhaltung der gängigen Strukturen (MVC usw.) hinzuweisen aber im endeffekt bin ich nur ausführender und muss meine Arbeitszeit rechtfertigen können und "UML- kästchen zeichen" kommt halt bei uns nicht so gut an

 

[maki]

Ich würde mal sagen, das sie einer 3 stufigen Architektur entspricht (Darstellung, Bussineslogik und Persistenzlogik)

Ja, sehe ich auch so.

Was haltet ihr davon?

Soweit ok.

Ich versteh schon, warum du (geplante?) schreibst, ich würde mir auch mehr Einsatz von UML, CASE o.ä. wünschen aber meine Vorgesetzen kennen sich da nicht aus.
Ich versuche trotdem so oft es geht UML einzusetzen und auch auf die Einhaltung der gängigen Strukturen hinzuweisen aber im endeffekt bin ich nur ausführender und muss meine Arbeitszeit rechtfertigen können und "UML- kästchen zeichen" kommt halt bei uns nicht so gut an

Ne, darauf wollte ich nicht hinaus, persönlich kann ich auch mit wenigen UML Diagrammen Leben und DIN A0 UML Tapeten sind ime eigentlich nutzlos, ausser man will Leute beeindrucken/verwirren.
Wollte eigeentlich nur einen Überblick bekommen, unabhängig vom Packet Diagramm oben.

Sehe ehrlich gesagt keinen Grund warum nicht alle Abhängigkeiten per Spring DI ausgelöst werden sollten.
Worüber du dir unbedingt klar sein solltest, ist, ob du zyklische Abhängigkeiten hast, diese am besten vermeiden, wenn es geht.

 

[Noctarius]

Auch wenn Spring eine sehr gute Lösung parat hat um zyklische Abhängigkeiten aufzulösen (wo es eigentlich nicht funktionieren würde wenn man es per Hand macht) sollte man sie trotzdem mit aller Kraft versuchen zu vermeiden, da weiterhin sehr unliebsame Nebeneffekte auftreten können.

 

[byte]

Bei einer richtigen Layer Architektur gibts sowieso keine zyklische Abhängigkeiten. Per Definition gibts ja immer nur eine Abhängigkeit von einer Klasse der oberen Schicht auf eine Klasse einer unteren Schicht, aber nie umgekehrt.

Also ein Service kennt ein DAO, aber ein DAO kennt niemals einen Service.

 

[Noctarius]

Natürlich alles sauber getrennt durch Interfaces ;-)

 

[MQue]

Hätte noch eine Frage zu Spring und den Abhängigkeiten,

in meinem Bild oben gibt es eine Package "tcpinterface", welches eine TCP- Verbindung zu einem Gerät aufbaut und dann ein Anfrage/Antwort- Spiel macht, d.h. also, dass in einer Klasse im tcpinterface- Package die aktuellen Daten vorhanden sind.
Die Daten werden aber in einer Klasse im "hibernate" (hab ich umbenannt auf de. ... . ... . persistenz) mittels DAO in die Datenbank geschrieben.
Meine Frage wäre jetzt, ob es mittels Spring eine Unterstützung gibt um die Daten (zyklisch) in das andere Package zu bekommen.
Wenn nicht muss ich es wie in meiner bisherigen Version mit dem Observer- Pattern machen.

 

[byte]

Keine Ahnung wovon Du sprichst. "Daten in ein anderes Package bekommen" - was soll das bedeuten?

Ein Package ist einfach nur ein Verzeichnis, wo Deine Klassen liegen. Das ist statisch...

 

[Noctarius]

So richtig verstanden habe ich auch nicht was du vor hast. Zumal das gerade nciht wirklich nach Abhängigkeiten klingt.

 

[MQue]

Keine Ahnung wovon Du sprichst. "Daten in ein anderes Package bekommen" - was soll das bedeuten?

Ein Package ist einfach nur ein Verzeichnis, wo Deine Klassen liegen. Das ist statisch...

Vielleicht hab ich es falsch Beschrieben, ich möchte die in einer Klasse zyklisch empfangenen Daten (package A) in einer anderen Klasse (package B) bekannt machen,

Ich weiß, das hat jetzt nicht viel mit packages zu tun.

Meine Frage ist, gibt es in Spring eine Unterstütung für einen Observer?

 

[Noctarius]

Du könntest den Observer per DI in die Empfänger-Instanz injecten.