[mateuszd]

Cześć Mireczki, ostatnio zacząłem nagrywać Kurs Spring Boota

Na razie nagrałem dwie części
1. Wprowadzenie do kursu i Autokonfiguracja
2. Kontekst, Inversion od Control i Dependency Injection

https://www.youtube.com/watch?v=G_AEiZqk_HM&list=PLLIGVl2WVN6ugud2cc3OShwWoTt65jzSL&index=2

W następnych częściach będzie jak tworzyć rest api i korzystać ze Spring Data

#spring #programowanie #java #naukaprogramowania #programista15k #nullpointerexception

[t.....4]

@mateuszd: czy Springa używa się w nowych projektach, czy to tylko samo utrzymanie?

[mateuszd]

@t3m4: używa się

[krasnoludkolo]

@t3m4: niestety używa

[tempname0626]

@krasnoludkolo: niestety?

[krasnoludkolo]

@tempname0626: ciężki, zachęca do złych praktyk, w większości niepotrzebny. Wszystko jest fajnie na początku, jak szybko działa, niestety potem szybko zaczyna się problem jak coś nagle przestanie działać i trzeba kombinować z jakimiś dzikimi haxami.

Co zamiast? Nie używać magicznego toola "do wszystkiego" tylko dobierać do konkretnych problemów. Chcesz mały serwer http? Weź jakiegoś ratpacka czy javalina. Dostęp do bazy? JOOQ.
Niestety trzeba pisać więcej kodu, ale za to masz

[globalbus]

@krasnoludkolo: takie pieprzenie "kuuurła, kiedyś to było". Autoconfigure do 90% zastosowań jest zajebiste, nie trzeba pisać kolejnego gównokodu do skonfigurowania poszczególnych modułów, a potem go utrzymywać.

I kto ci broni używać jooq w springboocie? Ja osobiście na wszystkie ormy i spring-data mam wywalone, ale resztę funkcjonalności łapię ile się da.

[krasnoludkolo]

@globalbus: autoconfig jest fajny, o ile zadziała. Problem jest taki, że czasem nie zadziała. I nie każdy ma czas, żeby rzucać 10k wyjątków podczas startu aplikacji ( ͡° ͜ʖ ͡°)

[krasnoludkolo]

ale ucziciwie trzeba przyznać, że integracje z różnymi dziwnymi rzeczami zazwyczaj działają ładnie

[krasnoludkolo]

już nie mogę edytować, ale dodatkowo fajnie byłoby wiedzieć już podczas kompilacji, czy coś się wysypie czy nie

[mateuszd]

@krasnoludkolo: autokonfiguracja zwykle działa. Jak dodajesz kolejne rzeczy do projektu, to oczywiście coś może przestać działać, ale to samo będziesz miał w innych frameworkach. Poza tym w springu nie masz narzucone żadnego komponentu. Jak chcesz, używasz Spring Data, jak nie chcesz, używasz Jooq czy czego tam chcesz, ty decydujesz.

[Gunnersaurus]

@globalbus: dlaczego masz wywalone w orm i spring data?

[globalbus]

@Gunnersaurus: nie mam potrzeby korzystania z ORM w codziennej pracy. Przy mnogości baz danych, które integruje, prościej jest mi napisać żywcem SQLa, niż zastanawiać się co wygeneruje automat.
Jedyny "ORM" z jakiego korzystam, to ten który sam napisałem, do obsługi obiektów na Oracle.

[cycun]

@mateuszd: Zbyt dużo osób jest, które nagrywają takie tutki o podstawach, a zbyt mało o jakichś grubszych rzeczach lub rzeczach, które omawiają jeden konkretny temat do podszewki.

[mateuszd]

@cycun: Jasne masz rację. Trochę się nad tym zastanawiałem i generalnie jest dwa powody. Pierwszy, chyba oczywisty, trudniej jest zrobić tutorial, który dotyczy trudnych rzeczy. Trudniej jest go przygotować, trudniej jest do nagrać. Drugi powód, trudne treści docierają do bardzo małej grupy odbiorców. Sprawdziłem to na swoim blogu. I jeśli mam do wyboru zrobić kurs, który już teraz ma ponad 400 wyświetleń (na moim świeżym kanale, nagrywam od miesiąca) lub

[draxgar]

@mateuszd: Nie oglądałem, ale mam nadzieję, że powiedziałeś ze @Autowired to zło, nie dobro i powód wszelkich złych praktyk w springu. Powiedz że to nagrałeś? Paragraf nad linkiem

The Spring team generally advocates constructor injection

Dla mnie @Autowired to ostatecznie tylko w testach, czasami i tylko jak nie ma innego sposobu (niektóre frameworki).

[mateuszd]

@draxgar: W drugiej części :D mówię o DI i tam powiedziałem, że zalecaną metodą jest wstrzykiwanie przez konstruktor. I od drugiej części wszędzie będzie wstrzykiwanie przez konstruktor.

[SiemkaKolego]

@draxgar: > Dla mnie @Autowired to ostatecznie tylko w testach, czasami i tylko jak nie ma innego sposobu (niektóre frameworki).

a to dlaczego? jaka jest różnica między @Autowired a np. wtrzykiwaniem przez konstruktor? Chyba taka, że jak masz serwisy gdzie masz podpięte 10 róznych klas to zamiast @Autowired masz konstruktor na 50 linijek

[draxgar]

@SiemkaKolego: Wstrzykiwanie przez konstruktor ułatwia testy. W teście tworzysz sobie klasę przekazując mocki, jeśli są potrzebne itp, tak by móc przetestować logikę. Nie stosujesz 'magicznych' sztuczek by zainicjalizować swój obiekt, bo nie musisz. Wszystko jest prostsze.

gdzie masz podpięte 10 róznych klas to zamiast @Autowired masz konstruktor na 50 linijek

To kolejny i bardzo ważny powód dla którego powinno się stosować konstruktor. Jak masz klasy które mają po 10

[SiemkaKolego]

@draxgar: Co do testów to jak masz pola z autowired w klasie którą testujesz, to w teście nie robisz magicznych sztuczek, tak samo sobie mockujesz poprzez adnotacje @Mock i tyle.

Ale w sumie co do drugiej części wypowiedzi to w sumie się zgodzę - wtedy odrazu widać że klasa może jednak robi za dużo. Tylko to fajnie brzmi w teorii - w praktyce mamy w pracy ze 2-3 klasy

[draxgar]

@SiemkaKolego: Ciesze się, że tak uważasz. Obyś nie widział tego co ja i dalej żył w błogiej nieświadomości. Nie widziałeś #!$%@?, gdzie masz 5 zagnieżdżeń i różne zależności między klasami. Różne kombinacje by w którejś z kolei gałęzi wstrzyknąć odpowiedni mock, bo nie możesz zamockować całej klasy, gdyż masz ją testować. Bawiąc się autowired, zbyt łatwo o takie zagnieżdżenie #!$%@? że nie idzie tego łatwo ogarnąć.

Swoją drogą w mojej