Spring Boot - Dependency Injection

[Heyoka955]

habe mal eine frage,
was ist beim spring boot dependency injection framework der unterschied zwischen @Component und @Autowired

sowie ich es verstanden habe, ist dass @Component dem Container vorgestellt wird, also wenn man über eine Klasse @Component schreibt dann wird diese Klasse dem Container vorgestellt und dadurch erhalten wir eine Bean. (aber mich würde es interesieren was genau dieses bean macht). Nachde wir eine Bean haben dann schauen wir was wir injecten wollen und schreiben @Autowired.

mein problem ist, was macht genau dieses bean?
ich weiß wie es aufgebaut ist, paramterloser konstruktor und mit getter und settern.

danke im voraus.

 

[httpdigest]

Was meinst du mit "Was macht das Bean"? Das Bean ist dann einfach eine Instanz deiner Klasse, die du in andere Klassen per @Autowired injizieren kannst. Dann hast du die Instanz dieser Klasse und kannst halt Methoden aufrufen, wie auf einer ganz normalen per `new` instanziierten Klasse. Von alleine macht das Bean nichts (es sei denn natürlich, du verwendest @Scheduled an einer Methode).

 

[Heyoka955]

Was meinst du mit "Was macht das Bean"? Das Bean ist dann einfach eine Instanz deiner Klasse, die du in andere Klassen per @Autowired injizieren kannst. Dann hast du die Instanz dieser Klasse und kannst halt Methoden aufrufen, wie auf einer ganz normalen per `new` instanziierten Klasse. Von alleine macht das Bean nichts (es sei denn natürlich, du verwendest @Scheduled an einer Methode).

Ah okay, und wieso ist deprndeny injection so bedeutend ?

 

[mrBrown]

Ah okay, und wieso ist deprndeny injection so bedeutend ?

Dependency Injection – Wikipedia

de.wikipedia.org

 

[Heyoka955]

Dependency Injection – Wikipedia

de.wikipedia.org

So dependency i jectuon dient zur Verdrahtung von Objekten.
Sie eignet sich hervorragend für Minimierung von Kopplungen.
Durch di ist es viel leichter einen Test zu schreiben um etwas zu testen.

Bsp haben wir einen konstruktor das ein funktionales Interface herstellt, dann ist es schwieriger dieses Interface zu testen da man nicht auf das Interface wirklich über den konstruktor zugreifen kann jedoch durch di kann man im Test lambda ausdrücke übergeben und so geshen werte und das ist der Sinn.
Die Abhängigkeit zu verringern und die Objekte zu verdrahten.

Soweit richtig ? Verstanden

 

[mrBrown]

Bsp haben wir einen konstruktor das ein funktionales Interface herstellt, dann ist es schwieriger dieses Interface zu testen da man nicht auf das Interface wirklich über den konstruktor zugreifen kann jedoch durch di kann man im Test lambda ausdrücke übergeben und so geshen werte und das ist der Sinn.

Ich habe keine Ahnung, was du mit einem "konstruktor das ein funktionales Interface herstellt" meinst...

So dependency i jectuon dient zur Verdrahtung von Objekten.
Sie eignet sich hervorragend für Minimierung von Kopplungen.
Durch di ist es viel leichter einen Test zu schreiben um etwas zu testen.
[...]
Die Abhängigkeit zu verringern und die Objekte zu verdrahten.

Das passt allerdings

 

[Heyoka955]

Ich habe keine Ahnung, was du mit einem "konstruktor das ein funktionales Interface herstellt" meinst...



Das passt allerdings

Okay muss für Klausur lernen.
Vllt Wechsel ich auf Wirtschaftsinformatik und kann das anrechnen lassen.

 

[AndiE]

habe mal eine frage,
was ist beim spring boot dependency injection framework der unterschied zwischen @Component und @Autowired

Wie der Name schon sagt, bedeutet das eine "Komponente" und das andere "automatisch verdrahtet". Was meinst du genau?

 

[Heyoka955]

Wie der Name schon sagt, bedeutet das eine "Komponente" und das andere "automatisch verdrahtet". Was meinst du genau?

Der Unterschied von den beiden anotationen?

 

[mrBrown]

Der Unterschied von den beiden anotationen?

Die Frage ist analog zu "Unterschied zwischen einem Karton und einer Liste".

Du könntest das ganze andersrum angehen, und nach Gemeinsamkeiten suchen: Beides sind Annotationen aus dem Spring-Framework.

 

[Heyoka955]

Die Frage ist analog zu "Unterschied zwischen einem Karton und einer Liste".

Du könntest das ganze andersrum angehen, und nach Gemeinsamkeiten suchen: Beides sind Annotationen aus dem Spring-Framework.

Ja weiter ?

 

[mrBrown]

Ja weiter ?

Nichts weiter, das sind im wesentlichen die Gemeinsamkeiten.

Um dir das an einem anderem Beispiel zu verdeutlichen: eine ähnliche Frage ist: "was sind Unterschiede zwischen Auto und Ampel."

 

[kneitzel]

Ich will ja kein Spielverderber sein, aber:

a) Wenn ich Spring Framework können müsste, dann würde ich mir das einmal von Grund auf rein ziehen. Klar, da kann man dann nicht den ganzen Tag Chillen aber dafür hätte man dann ein etwas besseres Wissen und vor allem einen Überblick über die Möglichkeiten, den Aufbau, ...
Somit wäre evtl. https://spring.io/guides ein guter Startpunkt.
Aber wenn es da eine Prüfung zu Spring Boot gibt: Dann gehörte dazu doch bestimmt auch eine Vorlesung / Übung. Somit müsste es schon eine Grundlage geben, auf der Du gut aufbauen könntest ...

b) Wenn ich wissen will, was @autowired und @Component sind, dann nutze ich Google.
Also Suchen nach
Spring Framework @Autowired:
- https://www.tutorialspoint.com/spring/spring_autowired_annotation.htm
- https://www.baeldung.com/spring-autowire
Spring Framework @Component
Hier kommen sehr viel mehr interessante Ergebnisse... So tauchen Vergleiche zwischen @Component, @Service und @Repository auf....

Okay muss für Klausur lernen.
Vllt Wechsel ich auf Wirtschaftsinformatik und kann das anrechnen lassen.

Und in Wirtschaftsinformatik muss man Vorlesungen / Übungen nicht besuchen und kann den ganzen Tag chillen?

 

[Heyoka955]

Ich will ja kein Spielverderber sein, aber:

a) Wenn ich Spring Framework können müsste, dann würde ich mir das einmal von Grund auf rein ziehen. Klar, da kann man dann nicht den ganzen Tag Chillen aber dafür hätte man dann ein etwas besseres Wissen und vor allem einen Überblick über die Möglichkeiten, den Aufbau, ...
Somit wäre evtl. https://spring.io/guides ein guter Startpunkt.
Aber wenn es da eine Prüfung zu Spring Boot gibt: Dann gehörte dazu doch bestimmt auch eine Vorlesung / Übung. Somit müsste es schon eine Grundlage geben, auf der Du gut aufbauen könntest ...

b) Wenn ich wissen will, was @autowired und @Component sind, dann nutze ich Google.
Also Suchen nach
Spring Framework @Autowired:
- https://www.tutorialspoint.com/spring/spring_autowired_annotation.htm
- https://www.baeldung.com/spring-autowire
Spring Framework @Component
Hier kommen sehr viel mehr interessante Ergebnisse... So tauchen Vergleiche zwischen @Component, @Service und @Repository auf....


Und in Wirtschaftsinformatik muss man Vorlesungen / Übungen nicht besuchen und kann den ganzen Tag chillen?

Ne ich hatte das Skript gehabt aber ich war unsicher ob ich das richtig verstanden hatte.

Aber scheint dass ich es verstanden habe.

 

[AndiE]

Aber scheint dass ich es verstanden habe.

Das glaube ich erst, wenn ich gelesen habe, wie du mit einfachen Worten den Zusammenhang zwischen DI, @autowired und @Component erklärst.

 

[Heyoka955]

Dependency injection ist dazu da um die Kopplung zu verringen.
Nehmen wir an wir haben eine klasse die ein Attribut hat und dieses Attribut hat ebenfalls eine Attribut also eine Abhängigkeit dann können wir durch Di die Kopplung verringern.
Mit Component machen wir dem Container eine Spring Bean bekannt was letzendlich ein Objekt ist, und dieses wird verwaltet von Container.
Dann haben wir @autowired, damit können wir so gesehen die dependency injecten und so die kopllung verringern.
Das heißt um zu injecten muss ic erstmal einen Spring bean erzeugen.

Es gibt field injection, setter injection und Konstruktor injecion

 

[AndiE]

Dafür würde ich keine Punkte geben.

Ich sehe das so:
1. Zwei Klassen, von denen mindestens eine die Methoden der anderen Klasse aufruft sind abhängig voneinander.
2. Um aus einer Klasse Bla eine Klasse Dup aufrufen zu können, wird üüblicherweise in der Methode "Bla.Do something()" ein Objekt von Dup instanziert.
3. Beim Einspritzen einer Abhängigkeit (DI) wird nun die Klasse Dup schon in der Klasse Lab instanziert und dann der Verweis der Klasse Bla bekanntgemacht.
4. In Spring erlaubt das Framework nun, dass die Verweise auf andere Klassen automatisiert werden können.
5. Dazu muss man einerseits einer Klasse erklären, dass sie verdrahtet werden kann, und nutzt dazu die "@component"
6. Wird in einer Klasse nun eine Instanz einer anderen Klasse aufgerufen, sorgt "@autowired" dafür, dass das Framework diese Abhängigkeit herstellt.

 

[Heyoka955]

[10 Punkte]
Wir haben eine Webanwendung geschrieben, mit deren Hilfe Versandaufkleber in der Ver-
sandabteilung gedruckt werden. Dazu senden wir einen Request an die URL

http://versand/printqueue?name=Jens&adresse=Universitaetsstr

Warum sollten wir f ̈ur den Request nicht das HTTP Verb GET verwenden?

A: Es gibt mehrere Gruende weshalb GET hierbei nicht funktioniert, zum einen darf GET keine Seiteneffekte erzeugen bzw den Zustand verändern und um eine Recource hinzuzufügen oder zu modifizieren muss man die Methode POST verwenden.



wäre gut wenn einer mir helfen könne, ob die antwort richtig ist?

 

[kneitzel]

Also so wie das da steht, ist das aus meiner Sicht nicht korrekt. Eine "Webanwendung" kann erst einmal machen was sie will, da gibt es erst einmal keine Regeln, die vorgeben, wann GET / POST / ... verwendet werden s oll.

Aber auf Grund der Antwort dürfte es sich um einen REST Webservice handeln soll, und da gelten dann gewisse Dinge, die z.B. auch unter https://de.wikipedia.org/wiki/Representational_State_Transfer zu finden sind.

Und da kannst Du ja mal schauen, was unter GET in der Tabelle steht ......

 

[Heyoka955]

Also so wie das da steht, ist das aus meiner Sicht nicht korrekt. Eine "Webanwendung" kann erst einmal machen was sie will, da gibt es erst einmal keine Regeln, die vorgeben, wann GET / POST / ... verwendet werden s oll.

Aber auf Grund der Antwort dürfte es sich um einen REST Webservice handeln soll, und da gelten dann gewisse Dinge, die z.B. auch unter https://de.wikipedia.org/wiki/Representational_State_Transfer zu finden sind.

Und da kannst Du ja mal schauen, was unter GET in der Tabelle steht ......

also dann hatte ich recht für den fall, denn wir fügen ja eine neue recurce hinzu und bei GET drfen wir das ja nicht aber bei POST soll man das sogar so machen.

 

[mihe7]

Es geht um die Formulierung Deiner Antwort, die in ihrer Absolutheit nicht korrekt ist:

Es gibt mehrere Gruende weshalb GET hierbei nicht funktioniert

Natürlich funktioniert ein GET, das ist technisch überhaupt kein Problem.

zum einen darf GET keine Seiteneffekte erzeugen, bzw den Zustand verändern

Kommt sonst die Web-Polizei und sperrt Dich ein?

und um eine Recource hinzuzufügen oder zu modifizieren muss man die Methode POST verwenden.

Muss ich nicht, wenn ich nicht will. Außerdem ist für Modifikationen nicht POST zuständig.

Die Fragestellung enthält nicht zum Spaß "sollte nicht", Du antwortest als würde da "darf nicht" stehen. Formulier die Antwort einfach der Frage entsprechend:

Es gibt mehrere Gründe, warum GET nicht verwendet werden soll. Zum einen wird bei REST-Services vorausgesetzt, dass GET keine Seiteneffekte besitzt, zum anderen ist die Anforderung über den Druck eines Versandaufklebers als neue Ressource (=Arbeitsauftrag) zu verstehen. Für das Hinzufügen neuer Ressourcen sollte POST verwendet werden.

 

[mrBrown]

Also so wie das da steht, ist das aus meiner Sicht nicht korrekt. Eine "Webanwendung" kann erst einmal machen was sie will, da gibt es erst einmal keine Regeln, die vorgeben, wann GET / POST / ... verwendet werden s oll.

Das kommt zT aus dem RFC zu HTTP:

In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
[...]


9.1.2 Idempotent Methods


Methods can also have the property of "idempotence" in that (aside
from error or expiration issues) the side-effects of N > 0 identical
requests is the same as for a single request. The methods GET, HEAD,
PUT and DELETE share this property.

 

[kneitzel]

Das kommt zT aus dem RFC zu HTTP:

Ah, das hatte ich so nicht im Hinterkopf, dass es da auch noch so vorgegeben wurde. Von wann ist diese RFC? Ich erinnere mich halt nur zu gut, dass am Anfang (ZU Zeiten des guten alten Netscape und so) bei Forms explizit POST und GET erläutert wurde und da die Unterscheidung nur war (so ich mich richtig erinnere), dass halt einmal alles auf der URL Leiste sichtbar war und beim anderen es im Body des Requests stand. (Oder irre ich mich hier jetzt? Ist zu lange her. Daher nur die Frage, ob dies mit http 1.1 gekommen ist oder ab wann das so vermerkt wurde.)

Aber ist auch nicht so wichtig. Auf jeden Fall ein sehr guter Hinweis, den ich so nicht im Fokus hatte!

 

[Heyoka955]

Das kommt zT aus dem RFC zu HTTP:

eine frage was ist gena mit idempotent gemeint? ist damit gemeint dass wenn man eine seite mehrmals aufruft dass sie dann immer das gleiche liefert also keine Änderung hat. Zbsp wenn ich eine Startseie öffne, bleibt der Zustand ja immer gleich.

unser dozent hat das sehr beschi.... erkläart

 

[mihe7]

ist damit gemeint dass wenn man eine seite mehrmals aufruft dass sie dann immer das gleiche liefert also keine Änderung hat.

Nicht ganz - es darf schon Effekte geben. Hat die Hintereinanderausführung mehrerer identischer Anfragen den gleichen Effekt wie die einzelne Anfrage, dann ist der Request idempotent.

 

[kneitzel]

Schon mal mit Google danach gesucht? Dann findest Du evtl. auch https://de.wikipedia.org/wiki/Idempotenz.

 

[mihe7]

Schon mal mit Google danach gesucht?

Das wäre zu einfach.