GoldenLine
Zaloguj się
Alchi Boski

Alchi Boski

Temat: pytanie o Spring, JSF i inne rozwiązania

Przyznam że od niedawna piszę w java ee głównie na localhost póki co :)
Używam mieszanki servlet, fasady EJB, JSP na TomEE i Glassfish. Mam dwa pytania - w czym pomoże mi Spring i czemu oficjalnie wspoera się JSF a JSP jest archaiczne i w odwrocie? Generalne pytanie dotyczy jakiejś znaczącej różnicy w bezpieczeństwie i komforcie organizacji pracy. Mi przeszkadza jedynie nieco tworzenie dwóch zestawów klas entity i facade jako osobnych bytów do potrzeb bazy danych ale poza tym wydaje mi się że wystarczy sobie raz napisać kilka klas zarządzających funkcjami takimi jak przekierowania z servletu na JSP i zadbać wygodne porównywanie danych w get i post i nic przyjemniejszego i szybszego nie wyobrażam sobie... Pierwsze pytanie więc czemu?

Drugie pytanie to prośba o pomoc: najwięcej problemów mam z entities które są niesforne i zależne od serwera... Na Tomee musiałem wygenerować i poprawić od nowa wszystkie klasy entity - a z tym jest całkiem ciekawa zabawa czasami - eksperymentuję więc z Tomee i aktualnie mam problem z łączeniem tabel - wpisywaniem obiektów jednej klasy jako typu danych w innej klasie entity - Glassfsh radził sobie z tym super. Jakieś rady? Probowałem kilku patentów z internetu ale życie nauczyło mnie że te wszystkie porady internetowe dają 90% ale nigdy 100% i zawsze trzeba samemu dojść do tego czemu oficjalne wersje i kod generowany przez automaty nie działa. Zwykle te drobne 10% stanowi o tym czy się zobaczy efekt czy nie...

A przy okazji - jak da się żyć bez EJB? np. na Tomcat... Czy to po to jest potrzebny Spring?

Dziękuję za odpowiedź!Ten post został edytowany przez Autora dnia 13.11.15 o godzinie 21:20
Link do wypowiedziLink
Michał Brzeziński

Michał Brzeziński JAVA [ * * * * o]
PHP [ * * * o o]
TypeScript [ * * o o
o...

Temat: pytanie o Spring, JSF i inne rozwiązania

zainteresowany odpowiedzią szczególnie na temat materiałów związanych z OpenEJB i Tomee. Glassfish posiada możliwość deklarowania relacji w @Jointable - Tomee wypluwa błędy bo nie wspiera, ale jakoś to się tam robi bo przecież nie szuka się w innej klase elementu po wartości klucza
Link do wypowiedziLink
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: pytanie o Spring, JSF i inne rozwiązania

Alchi B.:
Drugie pytanie to prośba o pomoc: najwięcej problemów mam z entities które są niesforne i zależne od serwera... Na Tomee musiałem wygenerować i poprawić od nowa wszystkie klasy entity - a z tym jest całkiem ciekawa zabawa czasami - eksperymentuję więc z Tomee i aktualnie mam problem z łączeniem tabel - wpisywaniem obiektów jednej klasy jako typu danych w innej klasie entity - Glassfsh radził sobie z tym super. Jakieś rady? Probowałem kilku patentów z internetu ale życie nauczyło mnie że te wszystkie porady internetowe dają 90% ale nigdy 100% i zawsze trzeba samemu dojść do tego czemu oficjalne wersje i kod generowany przez automaty nie działa. Zwykle te drobne 10% stanowi o tym czy się zobaczy efekt czy nie...
EJB jest technologią starasznie ciężką i słabo czytelną. Dużo lepszym rozwiązaniem jest przejście na Hibernate lub JPA (ORMs). Hibernate zapewnia obsługę obiektów trwałych (utrwalanych w bazie) a jednocześnie jest dużo bardziej czytelny i daje kontrolę nad każym aspektem mapowania obiektowo relacyjnego (ja preferuję annotacje w klasach danych trwały nad mapowanie w plikach XML). Poza tym Hibernete zapewnia mnóstwo możliwości, których w EJB nie ma lub u życie których jest bardzo skomplikowane (HQL, Criteria, złożone wyszukiwanie). W EJB najbardziej przeszkadzały mi bardzo mała elastyczność w mapowaniu obiektowo-relacyjnym, mała czytelność i autogenerowane klasy (o losdowych nazwach).
A przy okazji - jak da się żyć bez EJB? np. na Tomcat... Czy to po to jest potrzebny Spring?

Nie Spring nie jest do tego konieczny. Głównym zadaniem Spring było wstrzykiwanie zależności (IOC -inverse of control), co pozwalało zmniejszyć zależności pomiędzy modułami systemu. Na dzień dzisiejszy Spriing to olbrzymi kombajn "do wszystkiego" (np. zarządzanie transakcjami - może być zintegrowane z Hibernate, sieciowe MVC, usługi sieciowe [webservices] REST i SOAP, zaawansowane zarządzanie komponentami, zabezpieczenia aplikacji i wiele innych). Niestety Spring również jest dość "ciężki" w użyciu.

Jeśli twoja aplikacja nie jest olbrzymim "kombajnem" to nie warto zaprzęgać Spring'a. Wystarczy użyć Hibernate i jakiejś lekiej biblioteki do wstrzykiwania zależności (jest ich teraz sporo).
W JSP musisz pisać obsługę praktycznie każdego żądania protokołu HTTP. JSF poszło krok dalej i wprowadziło podejście komponentowe, jest dużo bardziej elastyczne i abstrakcyjne od JSP.
Z tak napisaną aplikacją nie powinieneś mieć problemów w dowolnym kontenerze servlet'ów np. wspomnianym Tomcat.

Na dzień dzisiejszy zarówno JSP jak i JSF są technologiami "obsolete".
Coraz częściej część serwerową aplikacji siecowej Java jest pisana jako usługa sieciowa (Webservice) REST, a cała część kliencka z wykorzystanie framework'ów Javascript (np. AngularJS - framework MVC by Google).

Pozdrawiam.
Link do wypowiedziLink
Alchi Boski

Alchi Boski

Temat: pytanie o Spring, JSF i inne rozwiązania

Może głupio spytam ale czy jako że JPA nie jest składnikiem EJB to czy praktycznie odejście od EJB w moim małym projekcie nie polega na tym że operujemy na tych samych entities tylko wyciągamy entity managera w fasadzie takiej jak ta generowana przez netbeans jako session bean tylko że robimy to bez dekorowania fasady jako @stateless (będzie zwykłym pojo)? a może na wstrzykiwaniu jej poprzez @inject a nie @ejb?
Link do wypowiedziLink
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: pytanie o Spring, JSF i inne rozwiązania

Alchi B.:
Może głupio spytam ale czy jako że JPA nie jest składnikiem EJB to czy praktycznie odejście od EJB w moim małym projekcie nie polega na tym że operujemy na tych samych entities tylko wyciągamy entity managera w fasadzie takiej jak ta generowana przez netbeans jako session bean tylko że robimy to bez dekorowania fasady jako @stateless (będzie zwykłym pojo)? a może na wstrzykiwaniu jej poprzez @inject a nie @ejb?

Odpowiedź na to pytanie nie jest całkowicie jednoznaczna (jednak w praktyce oznacza inny sposób obsługi "entity beans"):

Is JPA part of EJB 3.0 ?

Yes and no... Yes because every application server claiming to implement EJB 3.0 spec must also provide JPA implementation. No because JPA can be easily outside of EJB, in standalone applications or Spring-managed ones.

Parz te linki:

http://stackoverflow.com/questions/7945859/boundary-be...

http://stackoverflow.com/questions/4639535/ejb-3-or-hi...

http://stackoverflow.com/questions/8952730/how-does-ej...

Jak widać odpowiedzi na tak postawione pytanie są lekko rozbieżne.

Ja skłaniam się do opinii z drugiego linku: za pomocą Hibernate (ORM) można dużo prościej utrwalać obiekty w relacyjnej bazie danych. Ale EJB i JPA/Hibernate to różne technologie (EJB to
model komponentów - zarządzania ich cyklem życia a JPA to ORM). Tak się składa, że obie te technologie potrafią utrwalać kolekcje obi8ektów w bazie danych).

Spring+Hibernate to prostszy w użyciu odpowiednik technologii EJB.
Link do wypowiedziLink
Alchi Boski

Alchi Boski

Temat: pytanie o Spring, JSF i inne rozwiązania

Czasu chyba poznać inne techniki chociaż na potrzeby aktualnego projektu zostanę przy EJB. co będzie lepsze do korporacyjnego webservice zarządzającego kontami klientów? Czy EJB nie będzie bardziej wszechstronne? Np gdyby przyszło jednak stawiać jakieś nowe www w przyszłości. Na chwilę obecną www głównie jest na PHP.
Link do wypowiedziLink
Michał Brzeziński

Michał Brzeziński JAVA [ * * * * o]
PHP [ * * * o o]
TypeScript [ * * o o
o...

Temat: pytanie o Spring, JSF i inne rozwiązania

dla mnie spring jest sakręcony ;)
Link do wypowiedziLink

konto usunięte

Temat: pytanie o Spring, JSF i inne rozwiązania

Maciej G.:

EJB jest technologią starasznie ciężką i słabo czytelną. Dużo lepszym rozwiązaniem jest przejście na Hibernate lub JPA (ORMs).

Tak było rzeczywiście 10 lat temu, dziś EJB używa się nad JPA w celu opakowania w fasadę / transakcje itd nad kontrolerem czy innym frontem.

Polecam zrewidować spojrzenie na EJB, ponieważ Entity Beans są kompletnie archaiczną technologią. Nie można mylić EJB 2.x z EJB 3.x!
Maciej G.:

Spring+Hibernate to prostszy w użyciu odpowiednik technologii EJB.

Proszę nie wypisywać herezji ;) Polecam lekturę:
https://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/EJ...
http://www.adam-bien.com/roller/abien/entry/heavyweigh...
Link do wypowiedziLink
Michał Brzeziński

Michał Brzeziński JAVA [ * * * * o]
PHP [ * * * o o]
TypeScript [ * * o o
o...

Temat: pytanie o Spring, JSF i inne rozwiązania

Dokładnie.. ja nie mam dużego doświadczenia ale i obciążenia przyzwyczajeniami. Fasady to oficjalnie wskazywane przez Oracle rozwiązanie, w dużej części zautomatyzowane w Netbeans i nie postrzegałem nigdy EJB jako ciężkiej technologii, ale raczej jako wielofunkcyjną - chociażby REST Webserices i EJB, system adnotacji upraszczający koszmar ilości XML w konfiguracji aplikacji.
Link do wypowiedziLink
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: pytanie o Spring, JSF i inne rozwiązania

Marcin G.:
Maciej G.:

EJB jest technologią starasznie ciężką i słabo czytelną. Dużo lepszym rozwiązaniem jest przejście na Hibernate lub JPA (ORMs).

Tak było rzeczywiście 10 lat temu, dziś EJB używa się nad JPA w celu opakowania w fasadę / transakcje itd nad kontrolerem czy innym frontem.

Polecam zrewidować spojrzenie na EJB, ponieważ Entity Beans są kompletnie archaiczną technologią. Nie można mylić EJB 2.x z EJB 3.x!
Maciej G.:

Spring+Hibernate to prostszy w użyciu odpowiednik technologii EJB.

Proszę nie wypisywać herezji ;) Polecam lekturę:
https://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/EJ...
http://www.adam-bien.com/roller/abien/entry/heavyweigh...

Panie Marcinie,

pracowałem z technologią EJB 2.0 (do której się zraziłem z powodu jej skomplikowania i nieczytelności ) i wiem jak działa EJB 3.0. Pytanie brzmi tylko po co mam używać EJB 3.0 podobnie jak Spring(wybrane moduły) + Hibernate.
Spring na dzień dzisiejszy to również "ociężały" kombajn, jeśli zależy nam wyłącznie na IOC to wolę użyć jakiejś prostej biblioteki do tego celu +Hibernate do zapewnienia trwałości danych.

W EJB 2.0 nie było kontroli nad wieloma aspektami mapowania obiektowo-relacyjnego i proces ten był bardzo mało czytelny (w Hibernate od zawsze miałem nad tym procesem pełną kontrolę).

W EJB 3.0 nadal problem leży w większej komplikacji serwerów (np. Websphere Application Server).
Nie twierdzę, że EJB 3.0 to zła technologia -, tak samo jak nie twierdzę aby w prostszych projektach używać koniecznie Springa (którego stopień komplikacji nadzień dzisiejszy też jest bardzo duży.

EJB nadal ma sens w naprawdę złożonych aplikacjach klasy enterprise, które pracują na klastrach serwerowych (High-availability cluster za złożonym "load-balancing") z dużymi możliwościami skalowania aplikacji.

Pozdrawiam.
Link do wypowiedziLink
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: pytanie o Spring, JSF i inne rozwiązania

Michał B.:
Dokładnie.. ja nie mam dużego doświadczenia ale i obciążenia przyzwyczajeniami. Fasady to oficjalnie wskazywane przez Oracle rozwiązanie, w dużej części zautomatyzowane w Netbeans i nie postrzegałem nigdy EJB jako ciężkiej technologii, ale raczej jako wielofunkcyjną - chociażby REST Webserices i EJB, system adnotacji upraszczający koszmar ilości XML w konfiguracji aplikacji.

"Fasada" to wzorzec projektowy, który może być stosowany bez użycia EJB.

Patrz też ten link (czasem użycie Fasady może nie być optymalnym pomysłem):

http://stackoverflow.com/questions/5636764/why-use-fac...

"RESTful Web Service" to pojęcie całkowicie niezależne od EJB (a nawet od samego języka programowania Java). Nic nie stoi na przeszkodzie, aby używać "Restful Webservices" w Javie całkiem niezależnie od EJB, czy Spring.

W Hibernate/JPA Ty decydujesz, czy będziesz używać adnotacji (w klasach "persistent", który to sposób od "zawsze" preferuję), czy osobnego pliku XML). Nie każe Ci używać Springa, który na dzień dzisiejszy jest równie ciężki co EJB (można do tego użyć lżejszych bibliotek).

Mówiłem o powodach dla których wielu programistów zraziło się do technologii EJB (jak człowiek do czegoś się zrazi, dość trudno go przekonać, że nowe pod starą nazwą jest OK).

Popracuj z jakąś zło żoną produkcyjną instancją np. "Websphere Application Server" przez jakiś czas i daj znać, czy jest to bardzo przyjemne.

W EJB dla mnie zawsze, najgorsze było, że wiele rzeczy "działo się pod maską" i nie miałeś na to żadnego wpoływu bo robiły to za Ciebie "kontenery" lub inny software (np. generowane z losowymi nazwami klasy proxy itp).

Pozdrawiam.Ten post został edytowany przez Autora dnia 14.01.16 o godzinie 15:40
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

JavaServer Faces (JSF) 2.* ...




Wyślij zaproszenie do
Anuluj