Spring beans - Na czym polega ich idea?

Odpowiedz Nowy wątek
2017-01-04 13:18
bialyokon
0

Witam, czy byłby ktoś w stanie wytłumaczyć mi na czym polega idea
beanów w springu i dlaczego są aż tak "dobre" jak to wiele osób twierdzi ?

Pozdrawiam

Pozostało 580 znaków

2017-01-04 17:00
0

Na tym że ułatwiają testy na przykład


Nie pomagam przez PM. Pytania zadaje się na forum.
Pokaż pozostałe 15 komentarzy
@scibi92: przetestować repozytorium jednostkowo - normalnie ? Dla ustalenia: po pierwsze mogę mieć in process DB (i wtedy baza danych jest dla mnie takim pod komponentem jak klasa String). Mogę tą baze startować i inicjować w teście tak samo jak inne podkomponenty. Dla Ciebie integration test? Ja nie widze różnicy z unit testem. O ile tylko w teście testuję tylko ten kod, który jest klasie repozytorium. Zakładam, że baza (orm jeśli jest) są już przetestowane. - jarekr000000 2017-01-04 22:56
Repozytorium wcale nie musi się łączyć z bazą danych, bo to tylko abstrakcyjna kolekcja danych, pod spodem równie dobrze może być plik albo webserwis. A co do testów integracyjnych - jeśli ktoś je pisze w aplikacjach, które się z niczym nie integrują (w sensie nie mają zewnętrznych zależności), to chyba coś mu w życiu nie wyszło. - somekind 2017-01-05 02:38
@somekind - Albo wyszło - gdybym mógł pisać aplikacje co się z niczym nie integrują - to może i by było nudno, ale odpadła by większość powodów do wkurzania... Nie wiem czy to kiepsko :-). Pytanie co to są dla Ciebie zewnętrzna zależności i co testujesz testem integracyjnym ? Może przykład? Serio, bo najczęsciej testy integracyjne, które widze to właśnie: testujemy czy aplikacja działa- bo zrzucilismy robote kompilatora na runtime framework i już nie jesteśmy pewni czy wstanie.... A normalnie starczyłyby unit testy + kilka smoke testów. - jarekr000000 2017-01-05 04:02
Zewnętrzne zależności to zależności od innych serwisów/aplikacji/systemów. A testem integracyjnym sprawdzam komunikację z nimi w podstawowych przypadkach, czyli de facto są to takie smoke-testy. - somekind 2017-01-05 11:46
@somekind - dokładnie - to nie są żadne testy integracyjne -to są smoke-testy (integracyjne :-) ). Nie warto ich za wiele robić (warto energię poświęcić na lepsze unit testy) - bo i tak raczej nie da się ich zrobić dobrze (jak nie masz całkiem pod kontrolą takiego systemu). I nie ma to przy okazji nic do Springa i dyskusji wyżej. (Ale te testy to akurat niezależnie ciekawy temat -w zeszłym roku po raz pierwszy poznałem firme, która dobrze testuje... i jak dla mnie to mają : Unit testy - na poziomie całej infrastuktury). - jarekr000000 2017-01-05 12:07

Pozostało 580 znaków

2017-01-04 20:35
2

Bean jest w Javie taką „biznesową jednostką organizacji kodu”. W uproszczeniu. Historycznie beany miały zamykać w sobie pewną logikę biznesową/funkcjonalność biznesową. W praktyce okazało się, że pojęcie bean dobrze opisuje jednostkę kodu (zazwyczaj klasę), którą można za pomocą odpowiednich narzędzi wyposażyć w pewne dodatkowe funkcjonalności np. transakcyjność, aspekty czy też można ją testować w izolacji.

Jeżeli mówimy o beanach springowych albo o beanach CDI w sumie jeden czort w naszym przypadku, to mamy na myśli klasy, które są zarządzane za pośrednictwem Springa. Spring je tworzy, dodaje im zależności, traktuje je jako zależności, dodaje np. transakcje, jakieś dodatkowe implementacje itp. Co ważne taki springowy bean jest w pewnym sensie atomowy. W aplikacji będzie traktowany jako niepodzielny twór (nie oznacza, że samodzielny).

Zalety. Po pierwsze pozwalają na organizację logiki w odpowiednie warstwy. Po drugie, pozwalają na łatwiejsze tworzenie aplikacji, o ile przestrzegamy kliku reguł np. gadamy tylko po interfejsach, nie mieszamy warstw. Po trzecie, jako że gadamy po interfejsach, to można podmienić implementację tego, czy innego beana tak by zachowywał się w konkretny sposób, co jest przydatne w testach. Po czwarte, na kontener przerzucamy odpowiedzialność za weryfikację poprawności środowiska – kompletność modułów, odpowiednie ich powiązania itp.

Pozostało 580 znaków

2017-01-04 21:14
0
Koziołek napisał(a):

Zalety. Po pierwsze pozwalają na organizację logiki w odpowiednie warstwy. Po drugie, pozwalają na łatwiejsze tworzenie aplikacji, o ile przestrzegamy kliku reguł np. gadamy tylko po interfejsach, nie mieszamy warstw. Po trzecie, jako że gadamy po interfejsach, to można podmienić implementację tego, czy innego beana tak by zachowywał się w konkretny sposób, co jest przydatne w testach. Po czwarte, na kontener przerzucamy odpowiedzialność za weryfikację poprawności środowiska – kompletność modułów, odpowiednie ich powiązania itp.

Przy czym to wszystko oprócz punktu cztery zapewniają w Javie klasy i nie potrzeba żadnych Spring beanów.
Punkt 4 - jeśli twój program składa się z pluginów, które sobie w zależności od deploymentu różnie zestawiasz i konfigurujesz - to faktycznie Spring Beany jak najbardziej pomagają (i są wygodne).
Jeśli natomiast aplikacja zawsze składa się z tego samego kodu - to (do cholery!) kompilator + testy jest jednak całkiem dobry do sprawdzania powiązań i kompletności :P

A wady: Spring Beany dają zbyt dużo pokus do wstrzykiwania czegokolwiek gdziekolwiek (i rozwalania architektury). Aplikacja zmienia się w de fakto spaghetti oparte na globalnych singletonach. (ukryte pod płaszczykiem zwykłych obiektów ). Ja to znam jako przypadek ContextBeana - wiele dużych aplikacja w springu w końcu dorabia się tzw. ContextBeana, który trzyma wszystko :-) i jest wstrzykiwany wszędzie. (czasami nazywa sie RequestContext, czasem UserContext, - czasem jest takich kilka mniejszych).
Jak jest dobry zespół to oczywiście nic takiego nie będzie, ale po prawdzie to dobry zespół nawet w COBOLu napisze utrzymywalny kod. Fajnie jest jednak mieć środowisko idioto-odporne - Spring jest skrajnie nieodporny.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2017-01-04 21:14

Pozostało 580 znaków

2017-01-04 21:22
0

@jarekr000000: klasy oczywiście zapewniają, jednak spring wymusza pewne zachowania. Co do używania ContextBeana, to akurat jest zła praktyka i kod nie powinien przechodzić review.

Pozostało 580 znaków

2017-01-04 21:30
0
Koziołek napisał(a):

@jarekr000000: klasy oczywiście zapewniają, jednak spring wymusza pewne zachowania. Co do używania ContextBeana, to akurat jest zła praktyka i kod nie powinien przechodzić review.

Jedną z dobrych i prostych praktyką modularyzacji jest, taka że funkcja korzysta z parametrów które są podane jako argumenty (this to też argument). Spring akurat skłania do łamania tej zasady.
Zresztą chyba Ty nagrywałes prezentację na wrocław JUG ten temat :-)

Taka ciekawostka:
W Scali (też naJVM i robi siepodobne aplikacje jak w Javie) jakimś cudem nic takiego jak Spring sie na dużą "skalę" nie przyjęło - jest Guice (i nawet MacWire ) - ale po pierwsze duża cześć projektów w ogóle nie korzysta. A z tych projektów co korzystają to i tak na DI są zwykle zrobione tylko pojedyncze elementy/aspekty) - a nie cała architektura jak w typowym Javowym Webie.
(Fakt, że Scala ma kilka nice feaczerów -( implicit / lazy val/ traity), które poniekąd zastępują wstrzykiwanie na poziomie kompilatora... ale znowuż to nie jest tak, że cały kod w Scali to implicity...).

Kiedy pierwszy raz zobaczyłem Spring Beany - to była to doskonała łata na Javę 1.4 (która jeszcze nie miała generyków i nie można było zrobić dobrej "fabryki"...).
Potem twórcy springa dodawali rózne ficzery i był to użyteczny framework do robienia aplikacji pod java servlet.
Ale java sevlet to kolejna kupa i od kiedy jest Java 8 i są serwery typu Ratpack - Spring to po prostu architektura legacy. Sprawdzona i pewna. Ale śmierdzi.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2017-01-04 21:49
Tylko, że w Scali jak wspomniałeś masz dużo rozwiązań po stronie kompilatora. - Koziołek 2017-01-05 10:26
@Koziołek: i całkiem się liczę, że może w którymś z nowych projektów w Javie dojdę do ściany i będę musiał/chciał Springa wprowadzić. Na razie ciągle się nie zdarza się (nie robie aplikacji z pluginami). Zresztą jeśli ktoś połata braki javy Sprinigiem z sensem to ok - gorzej ,że prawie zawsze widzę rozwiązywanie problemów, kórych już nie ma (prawie wszystkie dekoratory) i magiczna wiarę, że słówko kluczowe 'new' jest jakoś wyklęte ( utrudnia testy...) i trzeba wszystko instacjonować w kontenerze. Czyli totalny Cargo cult. - jarekr000000 2017-01-05 10:43
@jarekr000000: inicjowanie w kontenerze to nic złego. poza tym spokojnie można wstrzykiwać przez konstruktor bez kontenera: inicjować sobie zależności na zewnątrz. mi się np. podoba, że kontener pozwala nam w prosty sposób określać jak długo obiekt będzie żył, czyli np. tylko request - margor90 2017-01-08 12:08
ja dla ułatwienia testów przestałem używać private, zamiast tego package i łatwiej zarządzam zależnościami zewnętrznymi, hermetyzuje wszystko na poziomie pakietu, to co domyślnie pakietowe jest dla mnie prywatne - margor90 2017-01-08 12:10

Pozostało 580 znaków

2017-01-04 21:30
0

Tak na prawde Beany nie sa niesamowita funkcjonalnoscia sama w sobie, a raczej umozliwiaja iplementacje innych funkcjonalnosci w szybszy/latwiejszy sposob.
1) Spring Security, z wlasnymi implementacjami, bez beanow, fajnie?
2) AOP bez beanow?
3) Controller Advice bez beanow?
4) Tworzysz jakis skomplikowany obiekt, thread safe, itd. Lepiej go sobie stworzyc gdzies w klasie konfiguracyjnej i tyle.
5) Zasieg beanow, tez ulatwienie.
6) Autoload properties i potem wstrzykiwanie tychze do konkretnych klas.

Wiekszosc springa opiera sie na tym, ze dokladana jest logika do beanow, kiedy sa one tworzone/juz stworzone.

A wady: Spring Beany dają zbyt dużo pokus do wstrzykiwania czegokolwiek gdziekolwiek (i rozwalania architektury).

Ale co maja beany do niewiedzy?!

Aplikacja zmienia się w de fakto spaghetti oparte na globalnych singletonach.

Jak sa thread safe, to czemu nie?

edytowany 5x, ostatnio: Mikajlo8, 2017-01-04 21:41

Pozostało 580 znaków

2017-01-04 21:49
0
Mikajlo8 napisał(a):

Aplikacja zmienia się w de fakto spaghetti oparte na globalnych singletonach.

Jak sa thread safe, to czemu nie?

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2017-01-04 21:52
0

Zaskocz mnie, i powiedz mi gdzie bede potrzebowal powodzenia:)

Pozostało 580 znaków

2017-01-04 22:05
0
Mikajlo8 napisał(a):

Zaskocz mnie, i powiedz mi gdzie bede potrzebowal powodzenia:)

W aspektach proszę ja Ciebie. Singletony Springowe opierają się o ThreadLocal i inne podobne cuda. I nie działa to z wątkami ani trochę dobrze. (To teraz jeden z największych problemów twórców Springa i Spring Reactive).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.

Pozostało 580 znaków

2017-01-04 22:22
0

Co niby nie dziala dobrze!?Daj mi przyklad aplikacji gdzie nie zaprzeczasz samemu sobie:

A wady: Spring Beany dają zbyt dużo pokus do wstrzykiwania czegokolwiek gdziekolwiek (i rozwalania architektury).

Aplikacja zmienia się w de fakto spaghetti oparte na globalnych singletonach.

(Niezwiazane z tematem) Rozmawiamy o aplikacji webowej ?

edytowany 1x, ostatnio: Mikajlo8, 2017-01-04 22:22
Ale gdzie jest jakaś sprzeczność? Tak dla ułatwienia rozmawiamy o aplikacji webowej. - jarekr000000 2017-01-04 22:35

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0