Spring beans - Na czym polega ich idea?

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

0

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

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.

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

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.

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

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?

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

0

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

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

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 ?

0

Odpowiadam w odpowiedzi, bo mi komentarza nie starcza.

W aplikacji webowej szkielet tworza Controller --> Service -->DAO, i pewne klasy ktore odchodza od nich.Beanami powinny byc klasy ktore tworza szkielet aplikacji tzn. ze Controller, Service i DAO powinny byc beanami(i niektore klasy ktorych one uzywaja).

Ty piszesz:

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.

a jednoczesnie piszesz:

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.* *

I tak sie zastanawiam, gdzie nie zaprzeczajac sobie ( wady: Spring Beany dają zbyt dużo pokus do wstrzykiwania czegokolwiek gdziekolwiek (i rozwalania architektury)), uzywasz executorow i beanow?

PS. Uzywanie executorow w aplikacje webowej juz wlacza czerwona lampke. Spring stworzy oddzielny watek dla kazdego requesta, i Ty jeszcze w tym watku dolozysz executora(Thread Pool?).

1
Mikajlo8 napisał(a):

W aplikacji webowej szkielet tworza Controller --> Service -->DAO, i pewne klasy ktore odchodza od nich.Beanami powinny byc klasy ktore tworza szkielet aplikacji tzn. ze Controller, Service i DAO powinny byc beanami(i niektore klasy ktorych one uzywaja).

Wg Ciebie tak powinno być. Wg mnie nie. W szczególności nic nie musi być beanami,

Ty piszesz:

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.

a jednoczesnie piszesz:

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.

Drugie zdanie odnosiło się do twojego "Jak sa thread safe, to czemu nie?". Bo. naiwne "thread safe" springowe (i java ee) robi zabawne problemy z wątkami.
Nadal nie widzę sprzeczności (a nawet związku) z moimi zdaniami wyżej.

PS. Uzywanie executorow w aplikacje webowej juz wlacza czerwona lampke. Spring stworzy oddzielny watek dla kazdego requesta, i Ty jeszcze w tym watku dolozysz executora(Thread Pool?).

I o tym pisze - to jest ta ciekawa wada Springa. Bo aplikacja Webowa nie musi działać na springu i nie musi tworzyć osobnego watku per request!! (btw. thread per request to akurat robi java servlet, a nie Spring, ale Spring bazuje na tym modelu).

0

Dyskusja jest o springu i beanach.

Odpowiesz mi na pytanie, gdzie zgodnie z definicja i przyjetymi zasadami dotyczacymi beanow i aplikacji springowych uzywasz executorow i beanow?

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.** **

?

0
jarekr000000 napisał(a):
Mikajlo8 napisał(a):

W aplikacji webowej szkielet tworza Controller --> Service -->DAO, i pewne klasy ktore odchodza od nich.Beanami powinny byc klasy ktore tworza szkielet aplikacji tzn. ze Controller, Service i DAO powinny byc beanami(i niektore klasy ktorych one uzywaja).

Wg Ciebie tak powinno być. Wg mnie nie. W szczególności nic nie musi być beanami,

Ty mowisz serio?Juz tu jeden byl co swoja baze danych pisal, a tu widze nastepny co architekture Springa bedzie zmienial.Nie, to nie wedlug mnie tak powinno byc, to wedlug tworcow Springa, po to stworzyli anotacje Controller, Service i Repository.

Ty piszesz:

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.

a jednoczesnie piszesz:

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.

Drugie zdanie odnosiło się do twojego "Jak sa thread safe, to czemu nie?". Bo. naiwne "thread safe" springowe (i java ee) robi zabawne problemy z wątkami.
Nadal nie widzę sprzeczności (a nawet związku) z moimi zdaniami wyżej.

Widzisz, ja znam definicje i sposoby uzycia beanow i nie wpadl bym na pomysl uzywania ich z executorami, no bo nie idzie sie w szpilkach na Giewont a po ulicy samochodem nie jezdzi sie pod prad.

1
Mikajlo8 napisał(a):

Dyskusja jest o springu i beanach.

Odpowiesz mi na pytanie, gdzie zgodnie z definicja i przyjetymi zasadami dotyczacymi beanow i aplikacji springowych uzywasz executorow i beanow?

To powodzenia w tworzeniu kodu pod Executors, ForkJoinPoole itp.** **

?

Wreszcie rozumiem o Co Ci chodzi. Odpowiedź praktycznie nigdzie - bo trzeba bardzo uważać. Dlatego właśnie Springowe beany są kiepskie.
Zarówno Spring (jaki i java ee) mają adnotacje i konstrukcje takie jak @Async, @EnableAsync etc, które na to pozwalają. Jednak jest zabawne o ilu rzeczach trzeba pamiętać, żeby
odpalić coś co w zwykłej javie jest po prostu trywialne. (dużo jest na StackOverflow problemów typu http://stackoverflow.com/questions/24798695/spring-async-method-inside-a-service)

A wątki, executory, schedulery, forkjoinpoole i inne takie - jednak są czasem przydatne i wygodne.

0

Springowe beany nie sa kiepskie.Ulatwiaja wieeele rzeczy, i to wszystko razem wspolgra jako cala aplikacja.

Z drugiej strony, Spring nie jest do wszystkiego, ale jak juz go uzywasz i piszesz, ze Controller, Service i DAO nie musza byc beanami, no coz, nasze opinie sa skrajnie rozne, bo ja uwazam ze musza(powinny).

Przeczytaj moje odpowiedzi do Twojego edytowane posta.

1
Mikajlo8 napisał(a):

Ty mowisz serio?Juz tu jeden byl co swoja baze danych pisal, a tu widze nastepny co architekture Springa bedzie zmienial.Nie, to nie wedlug mnie tak powinno byc, to wedlug tworcow Springa, po to stworzyli anotacje Controller, Service i Repository.

Primo:
Aplikacja Webowa nie musi być zrobiona w Springu.
Secundo:
Nie wiem dlaczego akurat ta Architektura miała by pasować do wszystkich problemów? See
Tertio:
Typowa implementacja Controller, Service i DAO jaką znam to tzw."Encja na twarz i pchasz" - i wynika właśnie z ogłupienia "patternami". Typowy Janusz najpierw zaczyna pisać na rympał MyController potem MyService, potem MyDao, a dopiero na koniec zerka co w ogóle zamówił klient i jakoś to tam wkleja w te klasy.
Quarto:
Ta architektura to pomysł sprzed 10 lat. Po lekkim podrasowaniu nadal się sprawdza w nowych aplikacjach zrobionych na REST (@RestConstoller).
Ale co jeśli aplikacja web korzysta głównie z websocketów i wysyła dane od serwera do klienta? (Btw. w springu nadal się to obsługuje @Controllerem - pasuje jak pięść do nosa )..

0
jarekr000000 napisał(a):
Mikajlo8 napisał(a):

Ty mowisz serio?Juz tu jeden byl co swoja baze danych pisal, a tu widze nastepny co architekture Springa bedzie zmienial.Nie, to nie wedlug mnie tak powinno byc, to wedlug tworcow Springa, po to stworzyli anotacje Controller, Service i Repository.

Primo:
Aplikacja Webowa nie musi być zrobiona w Springu.

No Tak, rozmawiamy o Spring Beanach a Ty mi mowisz, ze aplikacja nie musi byc w Springu?No nie musi, ale trzymamy sie glownego watku dyskusji(Od ktorego Ty odbiegasz)

Secundo:
Nie wiem dlaczego akurat ta Architektura miała by pasować do wszystkich problemów? See

Kompletnie sie pogubiles.Do wszystkich nie, ale do Aplikacji Webowych TAK.

Tertio:
Typowa implementacja Controller, Service i DAO jaką znam to tzw."Encja na twarz i pchasz" - i wynika właśnie z ogłupienia "patternami". Typowy Janusz najpierw zaczyna pisać na rympał MyController potem MyService, potem MyDao, a dopiero na koniec zerka co w ogóle zamówił klient i jakoś to tam wkleja w te klasy.

Tragedia...a typowy taki WSPANIALY PROGRAMISTA pisze w Springu ale nie uzywa beanow, dla kazdego request tworzy sobie jeszcze 10 watkow a reszta "Januszy" jak to nazwales, uzywa jakichs smiesznych paternow jak MVC.

Quarto:
Ta architektura to pomysł sprzed 10 lat. Po lekkim podrasowaniu nadal się sprawdza w nowych aplikacjach zrobionych na REST (@RestConstoller).
Ale co jeśli aplikacja web korzysta głównie z websocketów i wysyła dane od serwera do klienta? (Btw. w springu nadal się to obsługuje @Controllerem - pasuje jak pięść do nosa )..

Jak wysyla dane od serwera do klienta, to sa do tego specjalnie stworzone frameworki/technologie takie jak pusher.I powtarzam Ci jeszcze raz, Spring nie jest do wszystkiego, ale to do czego jest robi bardzo dobrze.

1
Mikajlo8 napisał(a):

No Tak, rozmawiamy o Spring Beanach a Ty mi mowisz, ze aplikacja nie musi byc w Springu?No nie musi, ale trzymamy sie glownego watku dyskusji(Od ktorego Ty odbiegasz)

Człowiek pyta w dlaczego są spring beany są dobre. A ja odpowiadam, że nie są. (już nie są). To jest główny wątek dyskusji.

Secundo:
Nie wiem dlaczego akurat ta Architektura miała by pasować do wszystkich problemów? See

Kompletnie sie pogubiles.Do wszystkich nie, ale do Aplikacji Webowych TAK.

Absolutnie nie. Inna architektura jest potrzebna do do obsługi sklepu ze zwierzatkami (tu może spring sie sprawdzic), inna do aplikacji typu twitter, inna do wikipedii, a jeszcze inna do czegoś jak facebooka. A to wszystko WEB.

Tertio:
Typowa implementacja Controller, Service i DAO jaką znam to tzw."Encja na twarz i pchasz" - i wynika właśnie z ogłupienia "patternami". Typowy Janusz najpierw zaczyna pisać na rympał MyController potem MyService, potem MyDao, a dopiero na koniec zerka co w ogóle zamówił klient i jakoś to tam wkleja w te klasy.

Tragedia...a typowy taki WSPANIALY PROGRAMISTA pisze w Springu ale nie uzywa beanow, dla kazdego request tworzy sobie jeszcze 10 watkow a reszta "Januszy" jak to nazwales, uzywa jakichs smiesznych paternow jak MVC.

No z pewnością - bo co jak co ale MVC na pewno do współcznesnego Weba wygodne i już mainstreamowe nie jest (see: MVVM, MVP). W szczególności SpringMVC.(Gdzieś się View zgubiło..., a i kontroller całkiem się zdegenerował przez ostatnich kilka lat). (inaczej: Janusze użwają SpringMVC i dlatego myślą, że używają MVC).

Quarto:
Ta architektura to pomysł sprzed 10 lat. Po lekkim podrasowaniu nadal się sprawdza w nowych aplikacjach zrobionych na REST (@RestConstoller).
Ale co jeśli aplikacja web korzysta głównie z websocketów i wysyła dane od serwera do klienta? (Btw. w springu nadal się to obsługuje @Controllerem - pasuje jak pięść do nosa )..

Jak wysyla dane od serwera do klienta, to sa do tego specjalnie stworzone frameworki/technologie takie jak pusher.I powtarzam Ci jeszcze raz, Spring nie jest do wszystkiego, ale to do czego jest robi bardzo dobrze.

A ja Ci powiem - dawniej w Javie jedyny rozsądny sposób robienia Web to było java servlet i spring i beany doskonale to ułatwił. Dodatkowo Spring łatał braki Javy. (Najpierw u zarania Springa brak generyków, a potem annotacjami brak lambd). Chwała mu za to. Ale java servlet to już nie jest jedyny sposób, są alternatywy - moim zdaniem często wygodniejsze (SparkJava lub Ratpack). Da się pisać teraz w Javie serwery HTTP prawie funkcyjnie - co znakomicie ułatwia testy. Spring bean nie pasują do tego ani trochę. (choć goście od spring-web-reactive ostro pracują, już w zasadzie jestem zaskoczony że to działa w ogóle).

Tak czy siak - od jakiegoś czasu ostro aktywnie hejtuje używanie Springa - bo to jedna z technologii (wielu), która głównie egzystuje na zasadzie Cargo Cultu - tak dziadowie robili i im działało - więc po co zmieniać. A większość powodów dla których używanie Beanów Springa miało sens... wyparowała. Zostało kilka - prawdopodobnie ich nie masz.

0
jarekr000000 napisał(a):
Mikajlo8 napisał(a):

No Tak, rozmawiamy o Spring Beanach a Ty mi mowisz, ze aplikacja nie musi byc w Springu?No nie musi, ale trzymamy sie glownego watku dyskusji(Od ktorego Ty odbiegasz)

Człowiek pyta w dlaczego są spring beany są dobre. A ja odpowiadam, że nie są. (już nie są). To jest główny wątek dyskusji.

Czlowiek pyta dlaczego Beany sa dobre a Ty mu odpowiadasz, ze nie sa bo nie za dobrze sie ich uzywa z Executorami w polaczniu z AOP. Czlowieku...

Secundo:
Nie wiem dlaczego akurat ta Architektura miała by pasować do wszystkich problemów? See

Kompletnie sie pogubiles.Do wszystkich nie, ale do Aplikacji Webowych TAK.

Absolutnie nie. Inna architektura jest potrzebna do do obsługi sklepu ze zwierzatkami (tu może spring sie sprawdzic), inna do aplikacji typu twitter, inna do wikipedii, a jeszcze inna do czegoś jak facebooka. A to wszystko WEB.

To mi teraz powiedz, gdzie ja napisalem ze MVC(i jego pochodne) to jedyny pattern?

Tertio:
Typowa implementacja Controller, Service i DAO jaką znam to tzw."Encja na twarz i pchasz" - i wynika właśnie z ogłupienia "patternami". Typowy Janusz najpierw zaczyna pisać na rympał MyController potem MyService, potem MyDao, a dopiero na koniec zerka co w ogóle zamówił klient i jakoś to tam wkleja w te klasy.

Tragedia...a typowy taki WSPANIALY PROGRAMISTA pisze w Springu ale nie uzywa beanow, dla kazdego request tworzy sobie jeszcze 10 watkow a reszta "Januszy" jak to nazwales, uzywa jakichs smiesznych paternow jak MVC.

No z pewnością - bo co jak co ale MVC na pewno do współcznesnego Weba wygodne i już mainstreamowe nie jest (see: MVVM, MVP). W szczególności SpringMVC.(Gdzieś się View zgubiło..., a i kontroller całkiem się zdegenerował przez ostatnich kilka lat). (inaczej: Janusze użwają SpringMVC i dlatego myślą, że używają MVC).

View sie zgubilo, ale Model i Controller zostaly, i caly czas uzywaja, i rozwijaja nowe funkcojnalnosci na tych beanach.

Quarto:
Ta architektura to pomysł sprzed 10 lat. Po lekkim podrasowaniu nadal się sprawdza w nowych aplikacjach zrobionych na REST (@RestConstoller).
Ale co jeśli aplikacja web korzysta głównie z websocketów i wysyła dane od serwera do klienta? (Btw. w springu nadal się to obsługuje @Controllerem - pasuje jak pięść do nosa )..

Jak wysyla dane od serwera do klienta, to sa do tego specjalnie stworzone frameworki/technologie takie jak pusher.I powtarzam Ci jeszcze raz, Spring nie jest do wszystkiego, ale to do czego jest robi bardzo dobrze.

A ja Ci powiem - dawniej w Javie jedyny rozsądny sposób robienia Web to było java servlet i spring i beany doskonale to ułatwił. Dodatkowo Spring łatał braki Javy. (Najpierw u zarania Springa brak generyków, a potem annotacjami brak lambd). Chwała mu za to. Ale java servlet to już nie jest jedyny sposób, są alternatywy - moim zdaniem często wygodniejsze (SparkJava lub Ratpack). Da się pisać teraz w Javie serwery HTTP prawie funkcyjnie - co znakomicie ułatwia testy. Spring bean nie pasują do tego ani trochę. (choć goście od spring-web-reactive ostro pracują, już w zasadzie jestem zaskoczony że to działa w ogóle).

Tak czy siak - od jakiegoś czasu ostro aktywnie hejtuje używanie Springa - bo to jedna z technologii (wielu), która głównie egzystuje na zasadzie Cargo Cultu - tak dziadowie robili i im działało - więc po co zmieniać. A większość powodów dla których używanie Beanów Springa miało sens... wyparowała. Zostało kilka - prawdopodobnie ich nie masz.

Cargo Cultu...

Hejtujesz, bo go nie rozumiesz.Jakiego Security Frameworku uzywasz?W ogole jakiego frameworku uzywasz do pisania webowych aplikacji czy napisales swoj wlasny?:)

Kolejny raz nie odpowiedziales na pytanie.Najpierw mowisz, ze teraz uzywane sa Sockety, to Ci pisze ze do tego sa specjalne technologies(push) a Ty piszesz cos co jest w ogole niezwiazane z temated.

Widzisz, ludzie uzywaja Springa, poniewaz musza skupic sie na wielu aspektach aplikacji(takich jak chociazby security).Bardzo latwo jest przyjsc, powiedziec, od dzisiaj nie uzywamy Springa tylko czegos innego, a potem jak sa problemy to znajdujesz nowa prace a firma zostaje ze sporymi problemami przez Twoja "Ideologie".

Pewnie, jestes zbyt zajety hejtowaniem Springa, i tego nie wiesz, ale jest on chyba najbardziej rozwijanym Frameworkiem z milowymi krokami jak Spring Boot, Spring Cloud itd.

2

Skoro Inne technologie jakoś obywają się bez beanów, i z powodzeniem powstają w nich działające aplikacje, to może jednak te beany nie są jedyną słuszną drogą?

2
Mikajlo8 napisał(a):

Tak czy siak - od jakiegoś czasu ostro aktywnie hejtuje używanie Springa - bo to jedna z technologii (wielu), która głównie egzystuje na zasadzie Cargo Cultu - tak dziadowie robili i im działało - więc po co zmieniać. A większość powodów dla których używanie Beanów Springa miało sens... wyparowała. Zostało kilka - prawdopodobnie ich nie masz.

Cargo Cultu...

Hejtujesz, bo go nie rozumiesz.Jakiego Security Frameworku uzywasz?W ogole jakiego frameworku uzywasz do pisania webowych aplikacji czy napisales swoj wlasny?:)

Normalnie jestem zwykle zmuszony używać security z websphere / java ee (nie pytaj - spring security jest zdecydowanie fajniejsze).
(akurat nie mam rozbudowanej w zakresie security aplikacji z dobrą alternatywą (pracuje nad jednym eksperymentem -ale to zupełnie inna bajka (nieprodukcyjna)).

Do robienia Web nie używam żadnego frameworku - a tylko bibliotek takich jak:
Akka-HTTP - w Scali (i tego najczęsciej)
Ratpack - w Javie (tego ciągle się uczę - ale ludzie zmuszają mnie do pisania w Javie - a od Ratpack jest najbliżej do Akka-HTTP).

Kolejny raz nie odpowiedziales na pytanie.Najpierw mowisz, ze teraz uzywane sa Sockety, to Ci pisze ze do tego sa specjalne technologies(push) a Ty piszesz cos co jest w ogole niezwiazane z temated.

Widzisz, ludzie uzywaja Springa, poniewaz musza skupic sie na wielu aspektach aplikacji(takich jak chociazby security).Bardzo latwo jest przyjsc, powiedziec, od dzisiaj nie uzywamy Springa tylko czegos innego, a potem jak sa problemy to znajdujesz nowa prace a firma zostaje ze sporymi problemami przez Twoja "Ideologie".

No widzisz, a ja Ciągle trafiam na firmy, które mają koszmarki Springowe...

Pewnie, jestes zbyt zajety hejtowaniem Springa, i tego nie wiesz, ale jest on chyba najbardziej rozwijanym Frameworkiem z milowymi krokami jak Spring Boot, Spring Cloud itd.

Ło matko.
Więc na co dzień w firmie pracuje i pisze kod + robię review do wielu aplikacji - powiedzmy 15 spośród 150(szacuje) jakie są utrzymywane w firmie. Jakiś czas temu składały się z ponad 1400 (tej liczby jestem pewny, bo widzę to w raportach) modułów w teamcity (ale to rośnie)). Z tego większość jest w JavaEE (pieknie...). Duża część jest Springu (objętościowo: połowa kodu który tykam). I bardzo mało - kilka nowych modułów i aplikacji bez tych cudów.
Wcześniej pracowałem w kilku firmach gdzie było raz JavaEE, raz Spring. Czasem oba na raz (EJB /CDI i Spring ). W sumie od 2000 roku. Jakieś trzy lata temu poznałem alternatywy. Doszła Java 8 i...
od jakiegoś czasu (rok?) hejtuje - bo widzę bezmyślność w ich używaniu i widzę jak niszczą kod. Wcześniej tego nie widziałem....

A teraz zadam Ci pytanie - w ilu innych technologiach poza Spring (w Javie) potrafisz napisać serwer HTTP i jakie masz porównanie?

I tak ogólnie - spadek po starych wersjach javy jest taki, że wielu się wydaje, że do wszytkiego (Security, HTTP, Persistence, Remoting) musisz mieć framework. Nie, nie musisz. Choć oczywiście granica między frameowkiem, a bilblioteką nie jest idealnie ostra.

1

Carco cult - fajne określenie. Niestety nie jest to kult spowodowany zajebistością, a lękiem przed zmianami i szukaniem dobrych rozwiązań. Każdy w pierwszej pracy stara się nauczyć jak najwięcej i przy okazji zepsuć jak najmniej. I ja na przykład przy pierwszym podejściu trafiłem do miejsca gdzie używano nowej JavyEE, ale z wieloma rozwiązaniami starych wersji. Serwis i interfejs do niego z sławetnym przedrostkiem ''I''. Czemu? Bo tak się pisze. No to tak pisałem. Gdy bawiłem się się do play framework ze scalą, to nie mogłem pojąć dlaczego nie ma tam wstrzykiwania zależności i w ogóle całej tej idei że w jednym frameworku można zrobić wszystko. To że często nie warto słuchać ludzi zrozumiałem po sporym czasie, gdy wyszedłem poza JEE i Springa.

Nie czuje że jestem złym programistą, ale nadal widzę sens stosowania springa. Być może z wiekiem i doświadczeniem zrozumiem że jestem w błędzie, ale na dzień dzisiejszy widzę zalety.

  • Po pierwsze, używając springboot można postawić aplikację naprawdę szybko. Do małych, palących projekcików jest super.
  • Po drugie, jest łatwy. Jeżeli już coś stoi to nawet junior który nie widział go na oczy szybko doda funkcjonalność. Tym bardziej że wszystko robione jest bardzo podobnie.
  • Po trzecie, jest szalenie popularny. Szansa że nowozatrudniony programista będzie znał springa jest duża. Szansa że będzie znał nowy lub niszowy stos jest mniejsza, a że będzie wiedział jak działają wewnętrzne autorskie mechanizmy jest dokładnie zerowa.

Podsumowujać IMHO:

  • spring jest dobry, ale nie jest lekiem na wszystko.
  • Warto samemu zastanowić się czu coś ma sens zamiast powielać rozwiązania, bo może nie mają już sensu.
  • Super działająca magia, pisana przez jedną osobę i bez doskonałej dokumentacji, to zła magia. Szczególnie jak ta osoba stwierdzi że z firmy sobie idzie, albo firma stwierdzi żę nie ma kasy na rozwijanie tej magii dalej skoro działa tak jak jest teraz.
0

@jarekr000000: a jak robisz transakcyjność?
Bo jestem bardzo ciekawy :D
Ps. Lepiej się dyskutuje za pomocą postów a nie komentarzy - przynajmnniej według mnie

0
scibi92 napisał(a):

@jarekr000000: a jak robisz transakcyjność?
Bo jestem bardzo ciekawy :D

Obstawiam że dekoratorem, tak jak spring, z tym że zakładanym ręcznie a nie poprzez proxy wykrywane adnotacjami.

1
krzysiek050 napisał(a):
scibi92 napisał(a):

@jarekr000000: a jak robisz transakcyjność?
Bo jestem bardzo ciekawy :D

Obstawiam że dekoratorem, tak jak spring, z tym że zakładanym ręcznie a nie poprzez proxy wykrywane adnotacjami.

Dokładnie.

Transakcyjność robię tak jak mi system, w którym pisze pozwala (lub każe).
Ale jeśli już musze SQL to wolę takie coś jak:
https://www.jooq.org/doc/3.6/manual/sql-execution/transaction-management/

Siłe tego widać dopiero jak się robi obsługę optimistic exceptionów ,automatyczne powtórzenia, kontrolę timeotów -wszystko jawnie w kodzie i dodatkowo łatwo komponować aspekty itp. Składanie funkcji to jest power.

1

@jarekr000000: masz jakąś aplikacje webową w Javie na githubie? Chodzi o coś więcej niż hello world

2
scibi92 napisał(a):

@jarekr000000: masz jakąś aplikacje webową w Javie na githubie? Chodzi o coś więcej niż hello world

Będzie - przygotowuje warsztat na ten temat.

0

Ja to bym chciał zobaczyć taką Springową aplikację przepisaną właśnie na nie-Springa. Ale żeby miała transakcje rozproszone (np 2 bazy i JMS), bo to jest w sumie dla mnie ficzer najważniejszy w całych kontenerach CDI.
W ogóle to rozmawiacie o narzędziach a nie ich zastosowaniu, bo jedni piszą web serwisy i mają te transakcje rozproszone a innym to nie jest potrzebne, ale zależy im na super skalowalności i wydajności

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