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