21 kwietnia 2009

Który szkielet aplikacyjny polecasz?

Dostałem dzisiaj wiadomość z grupy J Architects na LinkedIn o głosowaniu "Which one of the following is the best application framework". Jak można się domyśleć, moim wybranym na chwilę obecną jest Grails, więc nie miałem żadnych wątpliwości, na co postawić. Na razie Grails przoduje z 33% odpowiedzi, przed JBoss Seam i Wicket.

Poza Grails w szranki i konkury stanęli: JBoss Seam, Rails, Wicket i Tapestry. Sądzę, że wielu z głosujących nie ma bladego pojęcia, co można, a czego nie w pozostałych poza tym wskazanym (ja również należę do tej grupy), a i rozkład procentowy mógłby być inny w zależności od kryteriów (a może kryterii?!). Nie mniej jednak, dla mnie to był łatwy wybór, bo jestem na bieżąco z Grails i faktycznie odświeżył moje spojrzenie na tworzenie aplikacji webowych. Coś mnie tknęło (przez baaaardzo krótki moment), aby zagłosować na Wicketa, ale tak szybko, jak przyszło, szybko sobie poszło. Bardzo mi się podobał, ale podobnie jak z Grails, mam na jego temat bardzo powierzchowną wiedzę na bazie kilku domowych przykładów typu "Hello World" i tylko jedną...przeczytaną książkę. W przypadku Grails chociaż liczba książek jest większa (już dwie, a czekają kolejne!) i Groovy nie pozostawia złudzeń, co lubić. Pozostaje jeszcze JBoss Seam, który podobał mi się początkowo, bo łączył EJB3 i JSF, którymi się "upajałem" swego czasu, ale teraz?! Chyba nie robi na mnie wrażenia. W zasadzie jest powieleniem tego, co mam w Grails. Czasy pewnego zainteresowania JBoss Seam mam za sobą i teraz uważam, że EJB3+JSF są dobre jedynie dlatego, że są...specyfikacjami. Są jednak ciekawsze (lepsze?) rozwiązania, jak chociażby Groovy i wszechobecne DSLe w Grails, a nawet Wicket. JBoss Seam zawsze wydawał mi się jakiś przekombinowany i stosunkowo trudny w poznaniu (no pun intended! :)).

W głosowaniu znajdziemy również Rails i Tapestry, i jakkolwiek książka o Tapestry czeka na mnie, i potencjalnie będę miał na nią chęć, to o Rails nie mogę już tego powiedzieć. Zresztą Tapestry to dla wielu Wicket, a i nie inaczej jest z Grails i Rails. Jedynym powodem, dla którego rozważam zapoznanie się z Rails jest sam język Ruby (dopiero teraz zauważyłem, jak niedaleko jest między Grails a Rails - nawet nazwy języków są zbliżone - Ruby i Groovy. Ciekawe komu odbije się to czkawką?). Coraz częściej dochodzą mnie głosy, że nie ma co poświęcać czasu Railsom, skoro są Grailsy i że to dla ludzi ze świata PHP (chociaż Chlebik może sugerować inne myślenie migrując na Grailsy). Argument poznania kolejnego języka - Ruby - jest mimo wszystko zachęcający. W tym właśnie klimacie spoglądam na Scalę. Pisze się o nim (niej?) to tu, to tam i nawet pojawił się w komentarzu do głosowania jako...Lift (szkielet webowy w Scali). Chyba tylko nawał oczekujących mnie książek nie pozwala mi zająć się nim. Niech czeka cierpliwie (jak wielu klientów, którzy są skłonni zapłacić dobrze za dobrze wykonany projekt, a ostatecznie dostają jedynie dobre składowe z całością przypominającą Goliata - ufam, że moi tego nie doświadczają :)). Kiedy wczoraj przeglądałem prezentację integracji MS Excel i GlassFisha, a właściwie środowiska .Net i Java EE za pomocą WSIT z uwzględnieniem WS-Security (patrz prezentacja Aruna Gupty Excel using WSIT - Metro and .NET interoperability sample), dopiero otworzyłem oczy, jakie to cuda można wyczyniać znając różne rozwiązania, dobrane do problemu. To bodaj najstarszy problem informatyczny, aby dobierać właściwe narzędzia do problemu. Podoba mi się stwierdzenie "Kiedy masz pod ręką tylko młotek, wszystko dookoła wygląda jak gwóźdź". Ciekawe kto jest autorem tego powiedzenia, które tak trafnie oddaje stosunkowo powszechne podejście do rozwiązywania problemów. Przy tylu dostępnych szkieletach aplikacyjnych, aż dziw bierze, że udaje nam się wdrożyć tę maksymę w życie (a może właśnie, dlatego, że jest ich tak wiele, tak wielu się udaje?!). Przy okazji przeszukiwania Sieci w poszukiwaniu odpowiedzi, kto jest autorem trafiłem na bloga Nie tylko młotek - zapowiada się interesująco, bo na początek idzie Haskell i...Ruby!). O problemie młotka pisał ostatnio również i Sławek Sobótka na swoim blogu Holistyczna inżynieria oprogramowania - chociażby we wpisie DAO. Wiosenne porządki zostawiają odciski na rękach (po nieumiejętnym trzymaniu młotka) i dają się we znaki, co?!

Zainteresowanych głosowaniem zapraszam do mojego - "Który szkielet aplikacyjny polecasz?". Znajdziesz go na moim blogu w panelu po prawej. Przy 800 regularnych czytelnikach powinno się choć trochę wysondować polskie spojrzenie na temat. Do głosowania wchodzą wszystkie wymienione i kilka innych szkieletów aplikacyjnych, które przyszły mi do głowy (umieściłem nawet smalltalkowy Seaside, którym byłbym zainteresowany, gdyby ktoś tylko zechciał mi to wyłożyć - może temat na bloga?). Dodałem również kategorię "Inne", aby tam zgromadzić wiedzę na temat wykorzystania alternatywnych rozwiązań, być może wciąż niszowych, ale przyszłościowych. Pozwólcie mi poznać Wasze gusta, aby samemu zasmakować najlepszego i...oferować klientom jako własne za niewielką opłatą! ;-)

25 komentarzy:

  1. To ja głosuje na Strutsy, jako że znam je najlepiej i takie złe mi się nie wydają (choć znam kilka wad w specyficznych rozwiązaniach). Oczywiście nie zamykam się na rozwiązania inne. Niedługo postaram się poznać Seama - jako polecanego przez znajomych, którzy pracują z Java EE na codzień.

    Co do "kryteriów" i "kryterii" - to tego drugiego słowa nie ma w j. polskim :)

    OdpowiedzUsuń
  2. Może udałoby Ci się wypytać ich o powody, dla których tkwią/siedzą w Seamie? Chyba nie wyłącznie prostota wykorzystania EJB3 i JSF?! Coś funkcjonalnego też w nim znajdują, co? I w końcu dlaczego nie Grails?

    A z tym "drugim słowem" to jedynie odpowiem: "Mądrala się znalazł!" :P

    OdpowiedzUsuń
  3. Bo sie w nim szybko i sprawnie pisze.

    A nie grails, bo
    1) kiepsko sie go zna
    2) szef lubi Jave EE, a nie "jakies wynalazki";-)

    OdpowiedzUsuń
  4. Hej,
    Proponuje dodac Spring MVC i Spring Webflow. Oba popularne dosc. A na drugi chetnie zaglosuje;)

    OdpowiedzUsuń
  5. zdecydowanie tapestry 5. chociaz learning curve jest zabojczy, efekty jakie mozna uzyskac przy minimalnym nakladzie kodowania wszystko rekompensuja. to co do mnie przemawia w tapestry to m.in:
    - latwe wstrzykiwanie beanow springowych (@Inject MyBean myBean)
    - integracja z hibernatem, acegi
    - przejrzysty system templatow
    - elegancko rozwiazany problem uaktualniania obszarow strony (zones) za pomoca XHRow. prosta aplikacje ajaxowa mozna napisac wlasciwie nie znajac javascriptu
    - live reloading. brak koniecznosci restartowania serwera aplikacji zeby zobaczyc zmiany.

    to tak z grubsza tyle :)

    OdpowiedzUsuń
  6. ja byłbym za ajaxowym JSF+Spring IOC+JPA
    zatem oddaję głos na JSF :)

    OdpowiedzUsuń
  7. Ja oddałbym głos na Rails bo tylko je znam (nie pochodze ze świata PHP- nie znam PHP). A jest przecież JRuby działający na JVM.

    OdpowiedzUsuń
  8. - "Jaki framework polecasz ?"
    - "Właściwy!"

    Dziś może polecę Servlety i JDO bo hosting darmowy od Google ;)

    Zawsze znajdzie się odpowiedni klucz, żeby dobić śrubę :)

    Pozdrawiam,
    Krzysiek

    OdpowiedzUsuń
  9. @maciekmoczkowski: Właśnie! Zapomniałem o Spring MVC i WebFlow. Teraz już nie zmienię, ale odnotowane. Może pora zajrzeć do Grailsów. Tam to wszystko jest.

    @seban: Jest JRuby i Rhino, i Jython, i wiele innych portów - raczej nie starałem się wymienić ich wszystkich i wybierałem te wiodące w danej klasie, np. Rails dla Ruby, ale już nie Rails dla JRuby. To to samo.

    @Krzysiek: Przed momentem odpowiedziałem na podobnie postawione pytanie:

    Nic dodać, nic ująć - sama prawda. Tylko postaw się w roli studenta
    III roku informatyki, który po algorytmach, chciałby zacząć od czegoś.
    Może od JSP, może od servletów, dalej EJB3 i JSF, ale co dalej?! I
    tutaj pojawia się owe magiczne - "Który szkielet aplikacyjny
    polecasz?".

    OdpowiedzUsuń
  10. @Jacek Laskowski: Otóż, za Seamem przemawia:
    - leczy większość niedociągnięć jsf
    - podobnie z integracją jsf z jpa np. ExtendedPersistenceContext, BiJection
    - w miare przejrzyste przejścia pomiędzy ManagedBean, a EJB
    - integracja z JS
    - znaczne zmniejszenie ilości linii kodu w stosunku do klasycznego jsf+ejb+jpa
    - oraz oczywiście kontekst konwersacji
    - jak również wsparcie dla bookmarking

    OdpowiedzUsuń
  11. Nie wiem od kogo Ty usłyszałeś powiedzenie o młotku, ale zdaje mi się że w Danii jest to powszechnie znane powiedzenie (przysłowie?) :)

    Pozdrawiam

    OdpowiedzUsuń
  12. Jeśli chodzi o Ruby i RoR, ja kiedyś zacząłem się uczyć RoR, ale w pewnym momencie stwierdziłem (pewien pomocny człowiek z community mi w tym pomógł), że jednak najpierw trzeba nauczyć się Ruby'ego. Jest trochę rzeczy podobnych do javy, które jednak działają zupełnie inaczej. Np. private w javie i w rubym to nie to samo, przysłanianie pól w klasach też działa inaczej, jest trochę takich różnic które bardzo łatwo mogą wprowadzić w błąd. Teraz prawdę mówiąc zainteresowałem się Scalą. "Rozwalił mnie" fakt że jest binarnie kompatybilna z javą :)))

    OdpowiedzUsuń
  13. @Jacek - widzę, że wciągnął Cię ten grails. Czy mógłbyś napisać (albo skierować do odpowiedniego artykułu) do informacji jakie grails może mieć zastosowania? Czy da się w nim zrobić szybko coś, co miałoby jakąś większą logikę?
    Bo tak sobie na szybko przejrzałem chociażby http://www.grails.org/Success+Stories i widzę, że dotychczasowe zastosowania grails są w większości proste.
    Gdybym chciał mieć aplikację z 50 tabelami i kilkoma bardziej skomplikowanymi logicznie funkcjonalnościami to robiłbyś to w grails czy w seamie? Niech będzie aplikacja poziomu skomplikowania typu nieco JIRA (http://www.atlassian.com/software/jira/).

    OdpowiedzUsuń
  14. @bimki
    Ja mysle, ze to kwestia bardziej innego podejscia. Zalozmy taki ciag (frameworkowy):

    JSF/Struts - Seam/Tapestry - Grails

    I teraz kwestia jest bardziej w pytaniu, na ile funkcjonalnosc frameworka (zalozmy, ze znasz je wszystkie) jest najblizsza temu, abys zrealizowal funkcjonalnosc, ktora wymaga od ciebie klient. I tyle. Jesli okaze sie, ze potrzeba zakodowania serwisu glownie opartego o generowanie WebService z odsylaniem konktenu w XMLu i z masa roznych dziwnych udziwnien to czy jest sens rzucac sie na Grailsy? Nie wiem, na tyle nie znam innych frameworkow, ale moze lepiej faktycznie wyjsc z tych "najnizej" (JSF/Struts) i po prostu zakodowac potrzebna funkcjonalnosc i koniec.

    Z drugiej strony jak potrzebujesz frontendu do aplikacji dzialajacej na serwerze to wez Grailsy. Za pomoca scaffoldingu mozna napisac pol aplikacji w paru linijkach kodu. Parafrazujac motto z wpisu - dobierajmy mlotkek do wielkosci gwozdzia.

    Co do twojego pytania - nalezaloby zastanowic sie moim zdaniem nad 2 rzeczami - na ile programisci majacy to zakodowac znaja oba rozwiazania (Seam/Grails) i ile potencjalnie trzeba bedzie dopisac kodu by zrealizowac zakladana funkcjonalnosc. I tyle, odpowiedz powinna byc w tym momencie latwa. No chyba, ze jeszcze wchodza w gre inne kwestie (obciazenie serwerow, pozniejszy maintaince).

    OdpowiedzUsuń
  15. jak najbardziej się z Tobą zgadzam - należy dopierać młotek do wielkości gwodździa.
    Ostatnie 2-3 lata pracuję w jednej technologii - tzn. beehive, jsp, hibernate 2x. Jednak nasze aplikacje są już tak rozbudowane (i zakręcone), że dodanie 2 pól na formularzu to min. 2 dni roboty.
    To martwi, bo 2 pola powinny dać się dodać do bazy,dto,bdl i jsp w ciągu max pół dnia.

    Bardzo spodobała mi się konfiguracja jsf, spring, hibernate - w takim zestawie maintaince wydaje się być prostrzy.

    Grailsów nie znam w ogóle - trochę czytałem Jackowego bloga, ale na razie mnie to nie przekonuje :)

    Powiedz co miałeś na myśli jeśli chodzi o obciążenia? Masz jakieś doświadczenie jeśli chodzi o wymienione rozwiązania? Widziałeś jakieś testy porównawcze? Bardzo mnie to interesuje, bo zabieram się za pisanie czegoś nowego i chętnie poznałbym doświadczenia (lub wyniki jakiś badań) jeśli chodzi o wydajność działania...

    domyślam się (może błędnie), że taki Grails będzie wolniejszy od jsf+spring, ponieważ dużo dzieje się tam "samo", a takie "samo" oznacza generyczność, refleksje a więc (chyba) może mieć nieco negatywny wpływ na wydajność?

    pozdrawiam

    OdpowiedzUsuń
  16. Wzbudziło mnie:
    domyślam się (może błędnie), że taki Grails będzie wolniejszy od jsf+spring, ponieważ dużo dzieje się tam "samo", a takie "samo" oznacza generyczność, refleksje a więc (chyba) może mieć nieco negatywny wpływ na wydajność?I tutaj pełna zgoda, ALE...
    W Grails masz możliwość pisania aplikacji w "czystej" Javie - po prostu zamiast pisania w Groovy, piszesz bezpośrednio w Javie i masz kilka wywołań z Reflection API z głowy. Możesz nawet wyobrazić sobie sytuację, w której aplikację dzielisz na dwa moduły - wtyczki - i jedną część piszesz w Groovy, a drugą w Javie. Zysk polega na wykorzystaniu uproszczeń Grails, gdzie nie zależy/potrzeba martwić się o wydajność, a tam, gdzie ma to znaczenie idziesz w technologie "przy blachach". Spring jest w Grails i tutaj jest bezpośrednie jego użycie, więc nie różni się to od "czystej" konfiguracji JSF+Spring. Nie badałem wydajności aplikacji grailsowych, ale mam nieodparte wrażenie, że nie byłyby AŻ tak słabsze od tych, zbudowanych z tandemem JSF+Spring (jeśli założyć, że w ogóle byłyby słabsze, ale z braku przekonujących wyników pozostanę przy "słabszym" Grails). Zysku, którego nie da się nie zauważyć, to zdecydowane przyspieszenie czasu tworzenia takich aplikacji - dla praktyków JSF to pewnie niekoniecznie, bo nie znają Grails, ale już na pierwszy rzut oka widać, że wiele jest robione za nas, "samo" (i stąd przypuszczamy, że "może mieć nieco negatywny wpływ na wydajność"). Zakładamy również, że aplikacje JSF+Spring pisane są wydajnie (a to w wielu rozwiązaniach na nich opartych może nie być prawdą dla wielu zespołów). Wiele gdybania, więc jeśli nikt nie wykona testów wydajnościowych pewnie tak pozostanie (podpowiedź: ciekawa praca inżynierska!).

    OdpowiedzUsuń
  17. Jacku - masz rację, dużo gdybyania i nie ma co dłużej gdybać - trzeba wykonać test. Spróbuję zrobić w ciągu tygodnia jakiegoś CRUDa w obu technologiach, zapuszczę testy przez JMetera i zobaczę co wyjdzie. Jeśli nie skończy się na słomianym zapale, to podzielę się wynikami i źródłami aplikacji do analizy.

    Tylko pytanie - czy zwykły formularz typu "dodaj książkę" będzie miarodajnym testem?

    OdpowiedzUsuń
  18. Zacznij(my) od czegoś trywialnego, a później kolejne iteracje z coraz bardziej zaawansowanymi aplikacjami. Zresztą nawet tą samą funkcjonalność można zrealizować na kilka sposobów w danej technologii.

    OdpowiedzUsuń
  19. poczytałem trochę o groovym, coś popróbowałem ale na razie sobie to jednak odpuszczę - nie czuję tej technologii :( W Groovym tak jakby przestaje się mieć kontrolę nad tym co się dzieje - takie mam wrażenie. Pozostanę więc na razie przy jsf, a za jakiś czas znowu spróbuję...

    OdpowiedzUsuń
  20. Dla "studenta III roku" dałbym do rozważenia tylko pełne zestawy, więc np. Seam, Spring + Spring MVC + Hibernate, Grails w tej kolejności.

    Czemu takie?
    - po pierwsze muszą być pełne i zintegrowane, by nauka była efektywna
    - Seam bo standardy i przyszłość JEE będzie z grubsza tak wglądać, przychodzi razem z Hibernate, RichFaces i nie ma co się zastanawiać nad wyborem bibliotek a wiedza jest do wykorzystania w zawodze. No i dokumentacja RichFaces!
    - Spring bo jest "corporate-friendly", a z MVC pasuje w trochę inne zastosowania niż JSF.
    - Grails bo jest Groovy i szybko można efekty osiągać

    Ale to ogólnie jak ktoś jeszcze nie wie co chce zrobić. Jak wie co chce zrobić to zaczynamy od problemu i mniejszych klocków.

    @bimki
    Linked-In wykorzystuje Grails
    Twitter wykorzystuje Scala

    Koszt programistów zdaje się jest większy niż hostingu stąd zainteresowanie Grails. No a Scala nie ustępuje Javie ani trochę. Ba jest w stanie czasem wypaść lepiej (ale zwykle wtedy da się kod Java przyśpieszyć dodając trochę szumu).

    Nie rozumiem, uczucia braku kontroli? Powiedziałbym, że ma się jej wręcz za dużo...

    Pozdrawiam,
    Krzysiek

    OdpowiedzUsuń
  21. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  22. @Krzysiek
    A co byś radził zastosować w wykonaniu systemu podobnego w działaniu przykładowo do tego?:
    https://www.usosweb.uj.edu.pl/kontroler.php?_action=actionx:news/local()

    Czyli będzie wykorzystanie zaawansowanych transakcji. Przypuśćmy, że znam po części Seam, Spring. Ostatnio robię projekt w Richfaces+Hibernate.

    Z góry dzięki za pomoc!! Pozdrawiam

    OdpowiedzUsuń
  23. A jeszcze pragnę dodać, że jak tylko zaliczę sesję, bo niestety jeszcze jestem studentem;-), to zaczynam naukę Wicket i Grails. więc jestem otwarty na szkielet, lecz chciałbym uzyskać więcej informacji od ludzi(odnośnie mojego przyszłego projektu), którzy lepiej się ode mnie znają;-)

    OdpowiedzUsuń
  24. @Mariusz

    Patrząc pobieżnie na link uznaje, że potrzeba prostych kontrolek, formularzy, wyszukiwania, tabelek ze stronicowaniem, nie trzeba przekombinowanego desing... Zasadniczo wygląda na projekt w którym scaffolding się bardzo przydaje.

    Wszystko to Seam z Facelets i RichFaces daje Ci z pudełka. RichFaces i Seam mają bardzo dobrą dokumentacje, są dość corporate-friendly i bardzo bliskie aktualnych jak i przyszłych standardów, więc wiedza ma sporą szansę się przydać w pracy/CV.

    Seam ma statyczny scaffolding i obstawiam, że dokładnie to w tym projekcie byłoby bardzo przydatne.

    ps. zaznaczam, że w web nie siedzę praktycznie od 1,5 roku (wymyśliłem sobie wciągającą magisterkę), zalecam "use your own judgement"

    ps2. większa zabawa by była gdybyś pisał to w Grails ;)

    Pozdrawiam już z Polski,
    Krzysztof Kowalczyk

    OdpowiedzUsuń