Jeszcze parę lat temu mówiło się, że Spring i EJB wcale ze sobą nie konkurują. Każde z nich miało swoje obszary zastosowań, w których się sprawdzało, a drugiemu nie wchodziło w paradę. Wyhodowany na bolączkach EJB2 Spring Framework, rozwijany przez genialnych programistów z Interface21, świadomie pozbawiony był nadmiarowych bajerów EJB, przez co wypełnił tą niszę, w której potrzeba było minimalistycznego kontenera.
Z biegiem czasu dochodziły coraz to nowe dodatki: kolejne moduły, kolejne podprojekty, własny serwer aplikacji, SpringSource ToolSuite. Czy wciąż Spring i EJB mają swoje obszary stosowalności? Czy może stały się nawzajem dla siebie alternatywami? Porównajmy:
| SpringFramework | EJB3.* |
| bierzesz, co chcesz; w razie potrzeb dokładasz kolejne moduły | bierzesz wszystko albo nic; klejony na siłę koncept profili moim zdaniem tak bezsensowny, że nawet nie warto się rozpisywać |
| częste wydania | w bólach i na drodze kompromisów rodząca się specyfikacja jest sporo w tyle za nowinkami ze świata OpenSource |
| nastawiony na bezinwazyjne sklejanie fragmentów aplikacji oraz na integrowanie się z bibliotekami i frameworkami, które już istnieją i dobrze się sprawdzają | mityczna przenośność aplikacji pomiędzy serwerami |
| staje się coraz cięższy; może nie sam kontener ale włączając kolejne ficzery robi się coraz ciężej | zmierz w stronę odchudzania (JPA poza kontenerem, koncept profili) |
| Projekt OpenTerracotta spierający skalowanie aplikacji opartych o Springa | kontener EJB dostarcza możliwości skalowania aplikacji |
| można tworzyć aplikacje wielowątkowe | zakaz własnoręcznego korzystania z wątków; wątkami zarządza wyłącznie kontener |
| brak standardu dot. zarządzania aplikacją; istnieją projekty SpringSource dedykowane do tego celu | spójny sposób zarządzania aplikacją |
Okazuje się, że Spring wsparty bibliotekami zewnętrznymi potrafi zapewnić dokładnie te same funkcjonalności, że EJB. Być może jeszcze jedną różnicą jest to, że w przypadku Spring trzeba dokładnie wiedzieć jaki efekt chce się uzyskać, gdyż oferuje on bogactwo różnych opcji na rozwiązanie tego samego problemu i trzeba wiedzieć, która jest najodpowiedniejsza dla naszego projektu. W przypadku EJB, mamy wszystko out of the box.
Kontynuując tyradę narzekania
Kontynuując tę tyradę narzekanie trzeba wspomnieć jeszcze wiele genialnych frejmłorków i bibliotek, które świetnie wyglądają w 10 minutes tutorial, rozwiązują parę problemów i wprowadzają szereg nowych.
Wymieniam parę wad:
| JSF | ciężkie drzewo komponentów, pokręcony mechanizm renderowania; wersja 1.2 - toporna i wymagająca paru dodatków, aby sensownie pracować; wersja 2.0 - niby fajnie ale poużywamy-zobaczymy; RichFaces 4.0 wspierajace JSF 2.0 już jest |
| JPA | wolno rozwijająca się specyfikacja, plus wszystkie wady O/RMów |
| GWT | dostawca monopolista, ciężki klient, brak standardu, po stronie widoku obsługiwana jest tylko część maszyny wirtualnej |
| Struts2 | "prawie" wsparcie dla Ajaxa, koszmarne adnotacji |
| Spring WebFlow | fajny, gdy GUI ma charakter procesowo-kreatorowy, poza tym przerost formy nad treścią |
| Oracle ADF | w tutorialach genialny, w użyciu prowadzi do prawie takiego samego bałaganu w kodzie jak przy bezmyślnym klikaniu w Borland Delphi Buildera |
Co zamiast w/w?
Jakie mamy zatem mamy alternatywy? Co można używać zamiast powyższych rozwiązań. Spotkałem się z następującymi konfiguracjami:
- Stripes + dojo + Hibernate - wychodzimy z założenia, że nie ma co liczyć na automagiczne ajaxy i jeśli chce się mieć fajne GUI to trzeba w JavaScript popracować
- Freemarker + SpringMVC + myBatis - całkowita rezygnacja z JSP oraz pogodzenie się z faktem, że schemat bazy jest czasem tak prosty, że nie ma co przekombinowywać
- Oracle Forms, PowerBuilder - w architekturze dwuwarstwowej
- PHP - tak po prostu... to o wiele bardziej dojrzała technologia, niż jawowcom może się wydawać, mają nawet swoje automagiczne frejmłorki
Do czego właściwie nadaje się się JEE
Nie chcę za bardzo wyrokować, ale JEE rozważałbym wtedy, gdy...nie ma innego wyjścia, gdy z powodów historycznych (zastany stan systemu), ludzkich (umiejętności programistów) albo politycznych trzeba się decydować na tą konkretną technologię. Bardzo, ale to bardzo byłbym ostrożny, przy rozważaniu JEE dla aplikacji webowej. Dzisiaj jestem zdania, że do aplikacji strice webowych (i nic ponad to) JEE się nie nadaje: zbyt wolne, zbyt kosztowne (chociażby ze względu na wynagrodzenia programistów).
Do czego się nadaje. Oprócz wymienionych na wstępie powodów można jeszcze dorzuć szeroko rozumiany backend przy tworzeniu dużych i długotrwałych projektów o bogatym modelu - wtedy można doszukiwać się korzyści w inwestowaniu w JEE.
P.S. Wpis wyraża prywatne myśli autora, a autor nie zarzeka się, że myśli tych kiedyś nie zmieni:)
