Witam,
Aktualnie uczę się podstaw Springa z tej strony https://www.tutorialspoint.com/spring/index.htm
Prosiłbym o informację zwłaszcza od osób, które zawodowa pracują jako programiści Javy, co wybrać na początek nauki, jakie obrać kierunek.
Co aktualnie jest wykorzystywane w Javie EE.
Pozdrawiam.
Zawodowo programuję w JavaEE (juz 17 rok) proponuję abyś nie uczył sie tej technologii. Chyba, ze jakoś interesujesz sie archeologią.. W kategorii pieniedzy Cobol nadal przyniesie Ci wiecej, a wstyd moim zdaniem mniejszy.
Sama Java jest OK. Co do springa zdania są podzielone. Ja lubię tylko nowe kawałki ze Spring 5. Ale to co się uczysz jest szeroko używane i jest standardem. Da sie z tym żyć.
Btw JavaEE nie jest zupełnie martwe oczywiście - technicznie to Spring opiera sie o wiele standardów JavaEE i jest kompatybilny.
Natomiast żeby opisać stan JavaEE - to wystarzy jedno słowo ZombiEE. Nadal się rusza, ale nie spodziewaj się po tym nic dobrego. Jak Cię dopadnie - zeżre Ci mózg.
to tego, tutorial jest stary... nie mam na myśli, że jest zły, nauczysz się podstaw lecz obecnie są wykorzystywane dekoratory w kodzie, zamiast plików xml - zależy też czego oczekujesz od Springa? Co chcesz robić? Chcesz robić projekty on-the-fly i je oddawać po 3 tygodniach na produkcję, czy idziesz w kierunku wielkich projektów, w których struktura musi być usystematyzowana i czytelna dla wszystkich (czyli struktura z xml)?
Wszystko ma swoje plusy i minusy.
Jeśli chcesz robić projekty i je sprzedawać na szybkości, to dorzuć sobie jeszcze Kotlina lub Scalę. Kotlin jest przyjemniejszy, bo nie wymaga kolejnych bibliotek etc, wystarczy plugin do IntelliJ.
Co aktualnie jest wykorzystywane w Javie EE.
nie bardzo rozumiem?
trojanus napisał(a):
Co aktualnie jest wykorzystywane w Javie EE.
nie bardzo rozumiem?
Przeglądałem aktualne oferty pracy i pojawiają się różne technologie m.in: Spring framework, Hibernate, Angular itp.
I właśnie zastanawiam się na co zwrócić szczególną uwagę na początku, jak wiadomo nie możliwa jest nauka wszystkiego od razu.
Pomijam kwestie narzędzie typu Git, Maven (co jest standardem).
Znacie jakieś fajne tutoriale opisujące Springa(wiem, że jest rozróżnienie m.in na MVC, Web Service, Boot)
@Andrew00: to masz niewystarczające pojęcie. I mieszasz pojęcia.
MVC to jest wzorzec projektowy - proponuję poczytać na ten temat, bo to podstawa w Java/Spring lub JavaScript/TypeScript/Angular
W SpringFramework (Spring potocznie) wykorzystuje się wzorzec MVC.
Jeśli chodzi o Hibernate to jest to technologia, która umożliwia łatwą komunikację między Javą i SQL.
Angular to jest technologia frontendowa - czyli tylko po stronie przeglądarki.
Użycie Spring w 2017 spadło - prawdopodobnie na rzecz Java EE 7 (które prawie o tyle samo wzrosło):
https://dzone.com/storage/assets/5911393-dzone-guidetojava-volumeiv.pdf
(strona 5)
Wg mnie Hibernate'a warto znać niezależnie od własnych upodobań:
vpiotr napisał(a):
Użycie Spring w 2017 spadło - prawdopodobnie na rzecz Java EE 7 (które prawie o tyle samo wzrosło):
https://dzone.com/storage/assets/5911393-dzone-guidetojava-volumeiv.pdf
(strona 5)
Invalid or corrupted PDF file. Ale szczerze mówiac @vpiotr jakoś ciężko mi sobie wyobrazić żeby ludzie odchodzi od Springa do JEE, zwłaszcza jak mamy Spring Boot i Spring DATA
scibi92 napisał(a):
Invalid or corrupted PDF file. Ale szczerze mówiac @vpiotr jakoś ciężko mi sobie wyobrazić żeby ludzie odchodzi od Springa do JEE, zwłaszcza jak mamy Spring Boot i Spring DATA
Adam Bien w połowie roku mówił mi, ze jest jakiś szał na nowe pojekty w JavaEE. Ma mnóstwo zapytań między innymi w Polsce. Sam się dziwił.
Co nie zmienia faktu, że to wynaturzenie, które powinno odejśc do lamusa. (embedded servers, liberty itp. też).
Springowcy przynajmniej ewoluują - dorabiają nowe dobre częsci - za jakiś czas tylko powiedzą wywalcie annotacje i będzie spoko.
Kiedyś już zupełnie bez żenady powiedzieli: wywalcie XML i przejdźcie na annotacje, mimo, że wcześniej strasznie tego XML promowali :-).
Wierzę w nich - pieniądz nie śmierdzi, a w konkurencji na najgłupszy framework wiedzą, że z JavaEE (którego część nadal stanowi JSF) nie mają szans.
scibi92 napisał(a):
vpiotr napisał(a):
Użycie Spring w 2017 spadło - prawdopodobnie na rzecz Java EE 7 (które prawie o tyle samo wzrosło):
https://dzone.com/storage/assets/5911393-dzone-guidetojava-volumeiv.pdf
(strona 5)Invalid or corrupted PDF file. Ale szczerze mówiac @vpiotr jakoś ciężko mi sobie wyobrazić żeby ludzie odchodzi od Springa do JEE, zwłaszcza jak mamy Spring Boot i Spring DATA
Tu nie trzeba używać wyobraźni. To są badania na jakiejś tam grupie ludzi (użytkownicy dzone), które mogą ale nie muszą się przekładać na cały rynek.
Zesztą nie udawajmy, wybór JEE nigdy nie był podyktowany tylko technicznymi aspektami.
Myślisz że w korpo dyrektorzy czy osoby decyzyjne myślą o tym w czym chciałbyś pracować?
@jarekr000000: w jaki sposób promowali XML? Adnotacje pojawiły się po XML-u :) A frameworki IoC są generalnie popularne i duzo osób z nich korzysta nie tylko w Javie i jakoś nie widze żeby odchodziły do lamusa :P
@vpiotr no w sumie co do dyrektów IT masz rację. Kiedyś kolega opowiadiał że miał jakąs prostą statyczną strone HTML postawić... na jbossie :D :D :D
scibi92 napisał(a):
@jarekr000000: w jaki sposób promowali XML? Adnotacje pojawiły się po XML-u :) A frameworki IoC są generalnie popularne i duzo osób z nich korzysta nie tylko w Javie i jakoś nie widze żeby odchodziły do lamusa :P
No dokładnie promowali zanim pojawiły się annotacje - Spring 2.0 ( pierwszy z którego korzystałem) wylazł jak annotacje były calkiem nowe java 5.0 dopiero wyszła, a firmy nadal siedziały na 1.4 i 1.3 - więc nawet nie bardzo mieli wyjście. Pokazywali jak cydownie wszystko skonfigurować można w XML. Dopiero Spring 3.0 to szał annotacji i powolne przesunięcie "marketingu" w stronę: wywalcie XML. (przy Spring 4 już totalnie).
A co do argumentu dużo osób korzysta. Ja też korzystam - nadal uważam, że to katastrofa. W swoim kodzie sobie tego nie robię, ale jak trafiam do projektu ze Springiem to po prostu staram się trochę poprawić jak gdzies coś mieszam (zwykle wywalając wiele beanów i robiąc z nich normalne klasy Javy), ale całkiem rewolucji nie robię.
jarekr000000 napisał(a):
W swoim kodzie sobie tego nie robię, ale jak trafiam do projektu ze Springiem to po prostu staram się trochę poprawić jak gdzies coś mieszam (zwykle wywalając wiele beanów i robiąc z nich normalne klasy Javy), ale całkiem rewolucji nie robię.
@jarekr000000 rozumiem że po takowej zmianie puszczasz pełno testów i sporo klikasz w apce żeby mieć pewność że nic nie zepsułeś?
Pinek napisał(a):
jarekr000000 napisał(a):
W swoim kodzie sobie tego nie robię, ale jak trafiam do projektu ze Springiem to po prostu staram się trochę poprawić jak gdzies coś mieszam (zwykle wywalając wiele beanów i robiąc z nich normalne klasy Javy), ale całkiem rewolucji nie robię.
@jarekr000000 rozumiem że po takowej zmianie puszczasz pełno testów i sporo klikasz w apce żeby mieć pewność że nic nie zepsułeś?
Jeżeli po wywaleniu kilku beanow springowych trzeba przeklikiwac całą aplikację bo mogło się coś popsuć to znaczy, że ta aplikacja już jest bardzo zepsuta.
Normalnie przerobienie kilku beanów na normalnośc to nie jest operacja na otwartym sercu i kod nawet tego prawie nie zauważa.
Ale jakies dwa lata temu dostaliśmy z zespołem takie ultra chore Springowe aplikacje, wszystkie klasy to beany (jeszcze o nazwach typu AbstractCustomerManagerServiceBeanImpl (ten Abstract z Impl na końcu to nie żart, co więcej te klasy nie były nawet abstrakcyjne). Testy całe na mockach - czyli zawsze zielone, nawet jak się kod wywaliło.... (za to pokrycie prawie 100%).
Przenosisz klasę z pakietu do pakietu i apka się sypie...
Z tych aplikacji to springa MUSIELIŚMY wywalić, tak się dalej żyć nie dało. (nie ze wszystkich modułów się opłacało - ale krytyczne wyczyściliśmy).
No ale nazwanie ujowo klas to nie jest wina twórców Springa oO A wiele ludzi korzysta ze IoC bo lubią, i jest praktyczne.
Nadal mi ciezko wyobrazić aplikacje na 100 klas z logiką (nie mówie o jakiś DTO itp) i testowanie tego normalne. Zresztą jak przekazać do konstruktowa referencje, pisać 400 razy new? A Spring ułatwia testowanie, jak na przykład masz DataSource ustawiasz profil na test i masz inną baze danych, podnosisz konteks i normalnie wallsz requestami :) Ciekawe jak to przetestować lajtowo bez IoC, w 30 klasach podmieniasz String a url bazy danych? xD
scibi92 napisał(a):
No ale nazwanie ujowo klas to nie jest wina twórców Springa oO A wiele ludzi korzysta ze IoC bo lubią, i jest praktyczne.
Nadal mi ciezko wyobrazić aplikacje na 100 klas z logiką (nie mówie o jakiś DTO itp) i testowanie tego normalne. Zresztą jak przekazać do konstruktowa referencje, pisać 400 razy new? A Spring ułatwia testowanie, jak na przykład masz DataSource ustawiasz profil na test i masz inną baze danych, podnosisz konteks i normalnie wallsz requestami :) Ciekawe jak to przetestować lajtowo bez IoC, w 30 klasach podmieniasz String a url bazy danych? xD
Nie mam w 30 klasach URL do bazy danych... ale jesli Ty masz to Ci współczuję i powoli rozumiem dlaczego nie możesz sobie poradzić bez kontera IoC.
(btw. pewnie masz 30 razy wstrzyknięty PersistentContext - to ten sam rak tylko poziom dalej).
Kiedyś dawno temu (2001-2005) robiliśmy systemy w Javie, które juz były całkiem duże (na JavaEE głównie). Nie używaliśmy wtedy kontenerów IoC - Spring dopiero się rodził....
Nie mieliśmy 400 new, a testy mieliśmy. Te systemy oczywiście z dzisiejszej perspektywy są kiepskie. Ale programować tak, żeby poradzić sobie z zależnościami jeszcze umieliśmy - to dopiero potem nadszedł rak i Javowcy się oduczyli.
musicie być bardzo interesujący na imprezach
Hej, widzę dyskusja trwa w najlepsze, więc pozwolę sobie zdać małe pytanie - aby nie tworzyć kolejnego małego tematu.
Rozumiem, że konfiguracje XML to już daleka przeszłość, więc teraz używa się adnotacji javy czy "Configuration with Java Code" czy może jeszcze w inny sposób ?
Generalnie inwestuj czas w naukę pisania czystego, zrozumiałego kodu, który działa nawet, jak się go wyjmie z konkretnego frameworka. Tak naprawdę o to się cała dyskusja rozchodzi.
Jeśli pilnujesz tego, żeby np. potrzebne klasie zależności wrzucać wyłącznie przez konstruktor, żeby nie robić metod z ogromną liczbą argumentów (ale np. ograniczyć się do czterech), to Ci w pewnym momencie samo wyjdzie, gdzie potrzebne są adnotacje (albo gdzie się przydają), a gdzie zupełnie dobrze spisuje się zwykły kod Javy.
Ja osobiście właśnie tak robię w swoich aplikacjach i tego też uczę ludzi w zespole. Klasy mają tylko po kilka zależności, wszystkie da się łatwo wrzucić przez konstruktor. Singletony i pola static non-final są zabronione, większość klas ma niezmienny stan. Cały kod jest tak napisany, że można go poskładać, tworząc ręcznie obiekty i wrzucając w odpowiednie miejsca (co jest weryfikowane testami, które składają jakiś określony fragment systemu "na piechotę"). Jednocześnie korzystam z adnotacji @Inject tam, gdzie widzę, że to ma sens, bo robi dokładnie to, co chcę, żeby zrobiło*. Nie traktuję frameworków, ani narzędzi jako złotej kuli rozwiązującej wszystkie problemy. Efekt? Ludzie chwalą sobie tak napisany kod, chcą z nim pracować i mówią, że to ich rozwija. I w jakimkolwiek by frameworku nie zastosować tych zasad, one działają.
zyxist napisał(a):
Generalnie inwestuj czas w naukę pisania czystego, zrozumiałego kodu, który działa nawet, jak się go wyjmie z konkretnego frameworka. Tak naprawdę o to się cała dyskusja rozchodzi.
Podpisuje się pod całym postem - z jednym tylko zastrzeżeniem. Jak chcę robić serwery HTTP lub obsługę zgodnie z JavaEE/Spring ... to moim zdaniem tego się nie da zrobić czysto. Ten kawałek jest zawsze brudny (co gorsza niepotrzebnie). Tu sa Beany Injecty, Aspekty i inne bzdury...
Ale da się mi mo to jakoś żyć i tak własnie najczęściej w różnych projektach musze robić. I tak nie da się ich ( politycznie) wyciągnąć z websphera.
Jakkolwiek moim zdaniem - to najlepiej od tego syfu się całkiem odciąć.
@jarekr000000: no też nie mam, mam w jednej. Ale wyobraź sobie że masz na przykład klase A która zależy od klasy B a klasa B od klasy C
w tym momencie musisz w main zrobić tak:
A a = new A(new B (new C()))
A IoC to nie jest magia jak ktoś umie IoC. Większośc programistow generalnie nie umie dobrze programować więc stąd się rodzą problemy
Chętnie bym zobaczył przynajmniej fragment kodu aplikacji webowej, która ma klasy javove zamiast beanów (hmm przecież beany to POJO z annotacją). Jak przebiega flow czymś takim? Ciekawa dyskusja się zapowiada, no ale pisanie ze coś jest ujowe bo tak jest i tyle, albo ze jest ujowe bo ktoś kto to pisał jest cymbałem jest kompletnym absurdem. Jakieś solidne argumenty ? Chętnie bym przeczytał, dlaczego spring, ioc, beany to zuo. Jakieś linki?
Btw jakiś czas temu natknąłem sie na aplikacje baaaardzo starą w baardzo starej javie. Bylo JEE i 0 beanów. Cały flow polegał na przekazaniu dalej obiektu request w trakcie zmieniając jego stan. Czy coś takiego chcielibyście zobaczyć?
Interpod napisał(a):
Chętnie bym zobaczył przynajmniej fragment kodu aplikacji webowej, która ma klasy javove zamiast beanów (hmm przecież beany to POJO z annotacją). Jak przebiega flow czymś takim? Ciekawa dyskusja się zapowiada, no ale pisanie ze coś jest ujowe bo tak jest i tyle, albo ze jest ujowe bo ktoś kto to pisał jest cymbałem jest kompletnym absurdem. Jakieś solidne argumenty ? Chętnie bym przeczytał, dlaczego spring, ioc, beany to zuo. Jakieś linki?
https://blog.softwaremill.com/the-case-against-annotations-4b2fb170ed67
https://www.slideshare.net/holograph/slaying-sacred-cows-deconstructing-dependency-injection
Btw jakiś czas temu natknąłem sie na aplikacje baaaardzo starą w baardzo starej javie. Bylo JEE i 0 beanów. Cały flow polegał na przekazaniu dalej obiektu request w trakcie zmieniając jego stan. Czy coś takiego chcielibyście zobaczyć?
Raczej nie - stare JavaEE też miało pełno beanów EJB, tylko akurat nie było annotacji. Można powiedzieć, że były wszystkie wady posiadania kontenera i żadnych zalet.
Przekazywanie obiektu Request - masakra. Chociaż znam jeszcze gorszą patologię - niejawne przekazywanie Request (a raczej wpuszczanie danych w ThreadLocal): w postaci na przykład używania beanów Request Scoped. To dopiero jest mentalny fuck jak się śledzi skąd metoda bierze dane o użytkowniku, mimo że nikt ich do niej nie przekazuje.
scibi92 napisał(a):
@jarekr000000: no też nie mam, mam w jednej. Ale wyobraź sobie że masz na przykład klase A która zależy od klasy B a klasa B od klasy A
w tym momencie musisz w main zrobić tak:A a = new A(new B (new C()))
NIe musze, bo ja takich głupot nie piszę. Już Ci z 5 razy podawałem kod przykładowej aplikacji (jest nawet w tym wątku) - idź i zobacz gdzie tam są te tony new. Popraw na Springa jak potrafisz i znajdziesz gdzieś gdzie warto. Może przyjmę pull requesta :-)
scibi92 napisał(a):
@jarekr000000: no też nie mam, mam w jednej. Ale wyobraź sobie że masz na przykład klase A która zależy od klasy B a klasa B od klasy A
w tym momencie musisz w main zrobić tak:A a = new A(new B (new C()))
A IoC to nie jest magia jak ktoś umie IoC. Większośc programistow generalnie nie umie dobrze programować więc stąd się rodzą problemy
Ależ oczywiście, że nie musisz. I tak da się pisać aplikacje na więcej niż 100 klas i korzystać głównie z new i testować normalnie. W bardzo prosty sposób - wystarczy korzystać z modularyzacji. Na dany moduł (bounded context jak ktoś lubi) robisz jedną klasę konfiguracyjną w springu i tam metody oznaczone jako Bean, ale tylko te, które musisz. Resztę normalnie tworzysz przez new i tak powiedzmy, że masz obiekt, który potrzebuje X zależności z zewnatrz(innego modułu np) to leci po autowired przez parametry, a resztę wewnątrz tworzysz sam. Wtedy testowanie jest bajką, bo nie testujesz klasy X, tylko wywołujesz sobie konfigurację np abcConfig.getX() - opcjonalnie podając parametry, które są wymagane. I większość kodu da się pokryć unit testami.
@scibi92 -> jeśli masz klasę A zależną od klasy B, która zależy od A, to to jest problem z designem obu klas. Może to oznaczać, że próbujesz rozbić na dwie klasy kod, który wybitnie powinien być w jednej, albo że jedna z klas zajmuje się czymś, czym wybitnie nie powinna się zajmować. Albo że tylko wydaje Ci się, że one muszą być ze sobą powiązane. Zupełnie przypadkiem niedawno dostałem identyczne pytanie związane z pewnym kawałkiem kodu. Aby rozwiązać problem, wystarczyło sprawić, by klasa B nie wiedziała, że gada z A, bo po drodze był interfejs. Innymi słowy, przemodelowałem problem, by sprowadzał się do zagadnienia "klasa B zależy od czegokolwiek, co potrafi dostarczyć jej potrzebne informacje", a potrzebną instancję dostawała po prostu jako argument metody, która miała coś policzyć. I problem się rozwiązał.
@Interpod -> zgadzam się, że argumentacja "coś jest krzywe, bo jego autor jest cymbałem" to nie jest żadna argumentacja, a niektóre posty mogły tak wyglądać. Jednak pojawiło się też trochę merytorycznych argumentów w całej dyskusji. Próba kompletnego opisu wymaga napisania artykułu i chyba w niedługim czasie do stworzenia takowego siądę, skoro jest potrzeba. Tutaj zasygnalizuję tylko kilka ważniejszych myśli:
Podam Ci przykład, jak można stać się niewolnikiem narzędzia. Był sobie kiedyś taki framework webowy Apache Wicket. Jego ideą było to, aby aplikacje webowe pisało się podobnie, jak aplikacje okienkowe. Innymi słowy, miałeś komponenty ze swoim stanem, który trzymany był w sesji, a framework sam zarządzał, by w przeglądarce wszystko się odświeżało. Brzmi obiecująco, prawda? Kłopot w tym, że framework - próbując rozwiązać problem tworzenia aplikacji webowych - próbował zrobić z protokołu HTTP coś, do czego ten nigdy nie był projektowany. Po prostu styl tworzenia aplikacji desktopowych i webowych to dwa różne światy. Z jednej strony framework niby separował Cię od całej warstwy webowej, z drugiej - i tak nie mogłeś jej uniknąć, bo wyciekała ona w wielu miejscach, powodując zgrzyty (np. sesja ważąca kilkadziesiąt megabajtów). A gdy na taki zgrzyt trafiłeś, to trudno było coś na to poradzić, bo... byłeś niewolnikiem filozofii narzędzia, która się nie sprawdzała i byłeś zdany na jej łaskę bądź niełaskę. Ten sam problem, tj. tworzenie aplikacji webowych, można było rozwiązać w inny sposób: nauczyć się podstaw protokołu HTTP oraz podstaw tworzenia front-endów i backendów. Ilość wiedzy do zdobycia podobna, a efekt końcowy o wiele lepszy.
@jarekr000000: @zyxist doszło do pomylki miało być A od B i B od C. Na tak idiotyczny pomysł jak A zalezne od B i B zależne od A to bym nie wpadł :D
@scibi92: Fakt faktem że jeśli klasa A zależy od B, która to zależy od C, to ostatecznie musisz mieć tak czy siak instancje klas B i C. Jednak wydaje mi się że nie musisz tego robić w konstruktorze - może później, setterami? No chyba że faktycznie nie można stworzyć obiektu A bez obiektu B, albo że chcemy osiągnąć niemutowalność
Używanie setterów do prawdziwych obiektów (nie mam ma myśli jakiś opakowań na dane) to droga na onkologie jak dla mnie :)
Java 