Nie znam Spring i Enterprise JavaBeans, a tylko troche Java SE 8 i 9. Czy Spring i Enterprise JavaBeans maja zastosowania "tylko" do aplikacji webowych?
0
0
Nie tylko :) Możesz mieć różne typy aplikacji działających na backendzie, mogą to być np. aplikacje które czytają z kolejek JMS, aplikacje wykonujące batch taski, mogą to być też joby odpalane przez crona co jakiś czas
3
Ogólnie EJB to duża 
, a Spring to mała :
- Duża EJB powoli umiera w męczarniach i nowego kodu się w niej nie tworzy. Wymagała czegoś co się zwało Serwer Aplikacyjny jak np JBOSS. Jak ktoś się uprze i bardzo nienawidzi ludzi to można w tym nawet mikroserwisy pisać (czy dowolny modny backend)
- Mała Spring to EJB przeinaczone i poprawione przez społeczność - trochę lepsze, ale dalej . Jest to uniwersalne narzędzie które można wcisnąć wszędzie i napisać nawet aplikację desktopową ze Springiem. Ale że w większości w Javie pisze się backend to większość aplikacji z Springiem to też będzie backend. Core Springa toframework i kontener wstrzykiwania zależności
1
teofrast napisał(a):
Nie znam ... a tylko troche Java SE 8 i 9.
Jak najgorsze warunki do uczenia się tych technik. Bez **głębokiej **znajomości Javy, jedyne o czym możesz marzyć, to wklejanie złych i dobrych czarów z googla - bez zrozumienia
2
@teofrast: EJB tym się różni od Springa że wymaga kontenera aplikacyjnego. Spring IoC może być nawet w zwykłej aplikacji najprostszej jako zależnośc którą dociagasz w maven czy gradle.
Jako lekki framework do IoC polecam też Guice.
0
@scibi_92:
Tyle że jak w 2021 na rynku się mówi Spring, to na pewno się nie myśli "Spring IOC"
A to, co dziś znaczy "Spring", to też kontener, tyle że bez wyraźnej nazwy, i chyba bardziej pełny "czarów"
1
scibi_92 napisał(a):
@teofrast: EJB tym się różni od Springa że wymaga kontenera aplikacyjnego.
Nie. I jedno i drugie ma swoje wersje embedded, gdzie kontener jest osadzony w aplikacji startowanej z main (spring boot vs embedded ejb). Więc w sumie jeden pies.
0
@jarekr000000: dobra, źle może to ująłem, EJB wymaga chociaż tego embedded serwera z tego co się orientuję, zaś w Springu dajesz tylko w mvn zależność do Spring Core czy jak to tam się nazywa i jazda z koksem.
0
scibi_92 napisał(a):
@jarekr000000: dobra, źle może to ująłem, EJB wymaga chociaż tego embedded serwera z tego co się orientuję, zaś w Springu dajesz tylko w mvn zależność do Spring Core czy jak to tam się nazywa i jazda z koksem.
No ale jeśli dobrze rozumiem ideę embedded serwera to działa to jak embedded tomcat, prawda? Czyli też dodajesz zależność w pom.xml i jazda z koksem
1
KamilAdam napisał(a):
scibi_92 napisał(a):
@jarekr000000: dobra, źle może to ująłem, EJB wymaga chociaż tego embedded serwera z tego co się orientuję, zaś w Springu dajesz tylko w mvn zależność do Spring Core czy jak to tam się nazywa i jazda z koksem.
No ale jeśli dobrze rozumiem ideę embedded serwera to działa to jak embedded tomcat, prawda? Czyli też dodajesz zależność w pom.xml i jazda z koksem
Dokładnie. Co prawda różni dostawcy JakartaEE robią to różnie, jedni lepiej inni gorzej, ale taki wildfly to działał po prostu po wpisaniu zależności do pom.xml. Nie chciałbym bym tu przekonywać, że EE to takie same g**no jak Spring. Bo tak naprawdę jest dużo większe: jeszcze więcej magii, jeszcze gorsze testowanie.
0
No tak, ale żeby tworzyć beany w Springu nie potrzebujesz embedded Tomcata czy innego Wildfly.
0
No, ale potrzebujesz kontener springowy
UPDATE
- Żeby tworzyć beany w Springu potrzebujesz kontener springowy
- Żeby tworzyć beany w EJB potrzebujesz kontener EJB który może być embedded (lub zewnętrzny)
jaka tu niby jest różnica?
0
No tak, nie mniej jest on wygodniejszy i lżejszy.
0
Guice jest jeszcze lżejszy i IMHO wygodniejszy.
I co najważniejsze, żeby tworzyć Beany w Guice nie potrzebujesz kontenera springowego :P Dla mnie jest to killer feature :P
0
Odnośnie tej lekkości - chodzi mi o to że pobieranie Wildfly żeby mieć kontener do aplikacji w Swingu to duży overkill, dużo więcej zależności niż Spring Core.
@KamilAdam tak, uważam że Guice jest ok tylko nie o Guice OP pytał :pL