# Spring Boot - Dependency Injection



## Heyoka955 (2. Jul 2019)

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 (2. Jul 2019)

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 (2. Jul 2019)

httpdigest hat gesagt.:


> 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 (2. Jul 2019)

Heyoka955 hat gesagt.:


> Ah okay, und wieso ist deprndeny injection so bedeutend ?








						Dependency Injection – Wikipedia
					






					de.wikipedia.org


----------



## Heyoka955 (2. Jul 2019)

mrBrown hat gesagt.:


> Dependency Injection – Wikipedia
> 
> 
> 
> ...


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 (2. Jul 2019)

Heyoka955 hat gesagt.:


> 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...




Heyoka955 hat gesagt.:


> 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 (2. Jul 2019)

mrBrown hat gesagt.:


> 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 (2. Jul 2019)

Heyoka955 hat gesagt.:


> 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 (2. Jul 2019)

AndiE hat gesagt.:


> 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 (2. Jul 2019)

Heyoka955 hat gesagt.:


> 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 (2. Jul 2019)

mrBrown hat gesagt.:


> 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 (2. Jul 2019)

Heyoka955 hat gesagt.:


> 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 (3. Jul 2019)

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.... 



Heyoka955 hat gesagt.:


> 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 (3. Jul 2019)

kneitzel hat gesagt.:


> 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.
> ...


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

Aber scheint dass ich es verstanden habe.


----------



## AndiE (3. Jul 2019)

Heyoka955 hat gesagt.:


> 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 (3. Jul 2019)

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 (3. Jul 2019)

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 (3. Jul 2019)

[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 (3. Jul 2019)

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 (3. Jul 2019)

kneitzel hat gesagt.:


> 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 (4. Jul 2019)

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


Heyoka955 hat gesagt.:


> Es gibt mehrere Gruende weshalb GET hierbei nicht funktioniert


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


Heyoka955 hat gesagt.:


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


Kommt sonst die Web-Polizei und sperrt Dich ein?


Heyoka955 hat gesagt.:


> 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 (4. Jul 2019)

kneitzel hat gesagt.:


> 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".
> [...]
> ...


----------



## kneitzel (4. Jul 2019)

mrBrown hat gesagt.:


> 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 (4. Jul 2019)

mrBrown hat gesagt.:


> 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 (4. Jul 2019)

Heyoka955 hat gesagt.:


> 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 (4. Jul 2019)

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


----------



## mihe7 (4. Jul 2019)

kneitzel hat gesagt.:


> Schon mal mit Google danach gesucht?


Das wäre zu einfach.


----------

