EJB 3.1 lub Spring 3.. Kiedy wybrać który?

Question

EJB 3.1 lub Spring 3.. Kiedy wybrać który?

EJB osiągnęło wiele ulepszeń w 3.wersje x, Sprężyna jest również powszechnie używana, a wersja 3 jest dobrą alternatywą.

W SIECI Jest wiele artykułów, ale nie ma dokładnego porównania ejb3x z spring3x.. Czy masz jakieś pomysły na ich temat, w rzeczywistych przykładach, które z nich są lepsze w jakich warunkach?

Na przykład chcemy oddzielić db i server, co oznacza, że nasza aplikacja będzie na serwerze, nasza baza danych będzie na innym serwerze.. EJB remoting vs Cluster4Spring itd ?

Robienie wszystkiego jest zawsze dobre? konfiguracja nigdy nie jest potrzebna?

39

comparison ejb-3.0 spring-3 ejb-3.1

Author: asyard, 2011-08-16

Source

7 answers

Prawdziwe pytanie, które powinieneś zadać to CDI / EJB lub Spring

14

Author: David Blevins,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-27 22:53:18

To często nie Spring vs EJB, ale Spring vs Java EE. Sam EJB porównuje się do fasoli wiosennej. Oba są rodzajem zarządzanej fasoli biegnącej wewnątrz kontenera (kontener EJB resp. Pojemnik sprężynowy).

Ogólnie obie technologie są dość podobne. Reza Rahman zrobił świetne porównanie między nimi jakiś czas temu.

6

Author: Mike Braun,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-17 09:31:33

EJB są bardziej korzystne ze względu na standaryzację. Jeśli pracujesz z lekką aplikacją, myślę, że będzie Z Spring jest w porządku, ale jeśli spodziewasz się, że Twoja aplikacja będzie duża i będzie wymagała dużo dostępu do pamięci i dostępu do połączeń danych, możesz rozważyć rozpoczęcie rozwoju z EJBs. Głównym powodem jest klastrowanie i równoważenie obciążenia są wbudowane w ramy EJB.

W środowisku EJB, gdy Ear ('e' nterprise ' AR ' Chive) jest wdrożony, może być wdrożone z wieloma fasolami EJB, z których każdy może mieć określony cel. Powiedzmy, że napisałeś fasolę do zarządzania użytkownikami i inną fasolę do zarządzania produktami. Może pewnego dnia okaże się, że Twoje usługi użytkownika przewyższają usługi dostępu do produktów i chcesz przenieść użytkownika na inny serwer na innej maszynie. Można to zrobić w trybie runtime bez zmiany kodu. Beans może być przenoszony między serwerami i bazami danych, w celu dostosowania klastrowania i równoważenia obciążenia / danych bez wpływu na programistów lub użytkowników, ponieważ większość z nich można skonfigurować na poziomie wdrażania.

Innym powodem wspierania standardu jest świadomość, że większość dużych dostawców zewnętrznych prawdopodobnie go wesprze, co spowoduje mniej problemów podczas integracji z nowym standardem / usługą / technologią - i spójrzmy prawdzie w oczy, te wychodzą jak nowe smaki lodów. A jeśli jest w publicznej specyfikacji nowych firm start-up lub rodzaju deweloperów można utworzyć open-source wersja.

Http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

To najbardziej niefortunne, że nawet najbardziej inteligentni projektanci lub programiści nie mogą przewidzieć, które z ich funkcji mogą lub nie mogą zostać zaakceptowane przez społeczność programistów, co jest głównym powodem, dla którego oprogramowanie staje się nadęte... Java EE to zdecydowanie to!

6

Author: YP Leung,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-12 19:48:14

Wybierz jedno lub drugie, ale nie jedno i drugie.

Moje osobiste preferencje to wiosna. Przez ostatnie sześć lat korzystałem z projektów z wielkim sukcesem. Jest solidny jak każde oprogramowanie.

Spring może pracować z EJBs, jeśli zdecydujesz się mieć je w swojej aplikacji, ale nie wierzę, że odwrotność jest prawdą.

Polecam oddzielne maszyny fizyczne dla serwerów internetowych, aplikacji i baz danych, jeśli możesz sobie na to pozwolić.

Spring może pracować z kilkoma opcjami remotingu, w tym Usługi internetowe SOAP i REST. Porównanie fasoli wiosennej z EJB wykracza poza zakres tego pytania. Nie wiem, co to ma wspólnego z Twoją realizacją. Jeśli korzystasz z usług Spring POJO, są one w pamięci, a nie wymagają innego hopu sieciowego, takiego jak zdalne EJB. Pomyśl o prawie Fowlera dotyczącym rozproszonych obiektów: "Nie". Wprowadzaj opóźnienia tylko z dobrego powodu.

3

Author: duffymo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-18 11:44:35

EJB 3.1 jest najlepszym standardem dla aplikacji Java 6 EE.

Spring nadal nie obsługuje Java 6 CDI (weld) również nadal wiele zależy od konfiguracji XML. EJB 3.1 jest potężny i inteligentny.

Myślę, że Spring 3.1 nie potrzebuje żadnej konfiguracji XML. Możesz użyć adnotacji do konfiguracji.

2

Author: Armen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-05-15 14:29:25

Wspomniałbym tu o testach jednostkowych. We wspólnej aplikacji webowej (kontroler - > usługa->dane ->...- >widok) EJB i sprężyna zapewniają podobny wynik, ale sprężyna oferuje łatwiejsze testowanie.

W moim skromnym doświadczeniu sposób w jaki się rozwijasz jest inny w kilku aspektach:

Próba jednostkowa (zwycięstwo sprężyny). Wiosną robi się dość prosto do przodu, podczas gdy w ejb trzeba użyć Arqullian z ShrinkWrap (sic!), który działa wolno na każdej kompilacji.
Persistence (ejb wygrywa). Wiosną wokół tego jest walka, czyli google "jak autowireować trwałość w entity listener" http://bit.ly/1P6u5WO
Konfiguracja (ejb wins). Jako nowicjusz przybywający do wiosny z ejb zaskoczył mnie Rój adnotacji ipliki xml.

2

Author: Lauri,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-08-05 15:21:39

score 56 · Accepted Answer

W przypadku, gdy aplikacja działa na jednym serwerze, a baza danych na innym, wybór pomiędzy EJB i Spring jest nieistotny. Każda platforma to obsługuje, czy to aplikacja Java SE, prosty kontener serwletów jak Tomcat lub Jetty, PHP, Ruby on Rails, czy cokolwiek innego.

Nie potrzebujesz do tego żadnego wyraźnego remotowania. Wystarczy zdefiniować źródło danych, podać adres URL, w którym znajduje się serwer DB i to wszystko.

To powiedziawszy, zarówno EJB, jak i fasolka Wiosenna robią Ułatw pracę ze źródłami danych. Pomagają one w definiowaniu źródeł danych, wstrzykiwaniu ich w beans i zarządzaniu transakcjami z nimi związanymi.

Z tych dwóch, EJB (i Java EE w ogóle) jest bardziej lekki i bardziej przestrzega konwencji niż zasady konfiguracji. Spring wymaga większej szczegółowości, aby uzyskać te same rzeczy i zależy w dużej mierze od plików XML, które mogą szybko stać się bardzo duże i nieporęczne. Drugą stroną medalu jest to, że wiosna może być mniej magiczna i można Poczuj się bardziej pod kontrolą po tym, jak wszystko, co chcesz, jest napisane.

Kolejną kwestią jest sposób, w jaki EJB i Spring są rozwijane.

EJB jest wolny (jak w wolnym piwie), open-source i niezastrzeżony. Istnieją implementacje EJB realizowane przez organizacje non profit (Apache), firmy open source (Redhat / JBoss) i głęboko komercyjne przedsiębiorstwa o zamkniętym źródle (IBM). Ja osobiście unikałbym tego drugiego, ale dla każdego jego własnego.

Wiosna Z drugiej strony jest wolna i open-source, ale mocno zastrzeżone. Jest tylko jedna firma produkująca wiosnę i jest nią Springsource. Jeśli nie zgadzasz się z rodem, to masz pecha. Niekoniecznie jest to zła rzecz, ale różnica, o której warto wiedzieć.

Robienie wszystkiego jest zawsze dobre? konfiguracja nigdy nie jest potrzebna?

To naprawdę niekończąca się debata. Niektórzy twierdzą, że XML jest trudny do utrzymania, inni twierdzą, że adnotacje zanieczyszczają czyste POJO model.

Myślę, że przypisywanie fasoli jako bezstanowej EJB (@Stateless)lub encji JPA (@Entity) jest bardziej przejrzyste przy użyciu adnotacji. To samo dotyczy iniekcji zależności @EJB lub @Inject. Z drugiej strony wolę, aby zapytania nazwane JPQL były w plikach XML zamiast adnotacji, a zastrzyki, które reprezentują czyste dane konfiguracyjne (jak maksymalna wartość dla czegoś), również były w XML.

W Java EE każda adnotacja może być również określona w XML. Jeśli zarówno adnotacja i odpowiednik XML są obecne, XML nadpisuje adnotację. To sprawia, że naprawdę wygodne, aby rozpocząć od adnotacji dla domyślnego przypadku, ale zastąpić go później przez XML dla konkretnego przypadku użycia.

Obecne preferencje w Java EE wydają się być bardziej ukierunkowane na (proste) adnotacje połączone z dużą ilością konwencji nad konfiguracją.