Wszystkich zaniepokojonych brakiem nowych postów (są tacy w ogóle? ;) chciałem uspokoić, że blog nie umarł, tylko chwilowo przeszedł w stan uśpienia. Powodów takiej sytuacji jest kilka: dużo pracy w pracy, zamieszanie sesyjno-zaliczeniowe i najważniejsze, moja magisterka.
Nadchodzi czas intensywnego pisania, więc moja uwaga skoncentrowała się właśnie na tym. Przy okazji miałem okazję "zaprząc" do pomocy społeczność polskich programistów Java, bo miałem kilka wątpliwości odnośnie zakresu mojej pracy. Odpowiedzi kilku osób w tym temacie na GoldenLine oraz w wątku "Porównanie frameworków JEE - prośba o pomoc [trochę długie]" na pw.comp.lang.java dały mi trochę wskazówek, co jeszcze warto wziąć pod uwagę w mojej pracy i jakie jeszcze frameworki w niej można zawrzeć.
W tej chwili główna część pracy będzie wyglądała następująco:
ROZDZIAŁ VIII: PORÓWNANIE FRAMEWORKÓW
VIII.1. PORÓWNANIE BUDOWY
VIII.1.1. Architektura
VIII.1.2. Cykl życia żądania
VIII.1.3. Sposób konfiguracji
VIII.1.4. Warstwa prezentacji
VIII.1.5. Budowa przykładowej aplikacji "Hello World"
VIII.2. PORÓWNANIE FUNKCJONALNOŚCI
VIII.2.1. Walidacja i automatyczna konwersja danych
VIII.2.2. Stanowość interakcji i obsługa konwersacji
VIII.2.3. Nawigacja między stronami
VIII.2.4. Bezpieczeństwo: uwierzytelnianie i autoryzacja, wsparcie protokołu HTTPS
VIII.2.5. Internacjonalizacja
VIII.2.6. Wsparcie dla captcha
VIII.2.7. Przyjazne adresy URL
VIII.2.8. Integracja z technologią AJAX
VIII.2.9. Prezentacja danych na wykresach
VIII.2.10. Integracja z frameworkiem Spring
VIII.2.11. Tworzenie własnych komponentów
VIII.3. PORÓWNANIE DOSTĘPNOŚCI I POPULARNOŚCI
VIII.3.1. Literatura polsko i obcojęzyczna
VIII.3.2. Aktywność list dyskusyjnych
VIII.3.3. Popularność wśród pracodawców i w Internecie
VIII.4. PORÓWNANIE WYDAJNOŚCI I SZYBKOŚCI DZIAŁANIA
VIII.4.1. Statystyki obciążenia serwera
VIII.4.2. Pomiar szybkości działania aplikacji przy dużej liczbie użytkowników
Ciągle nie podjąłem ostatecznej decyzji jakie frameworki chcę porównać. Porady innych programistów trochę mi zamieszały w głowie i w tej chwili waham się pomiędzy kilkoma opcjami. Pewniakiem jest Wicket, który znam i lubię :) Po głowie chodzą mi również:
- Java Server Faces, bo jest popularny, wspierany przez Sun i warto byłoby go lepiej poznać. Jednak z JSF jest moim zdaniem taki problem, że aby coś sensownego na nim zbudować, trzeba skorzystać z paru innych bibliotek, a w takim wypadku porównywanie JSF z innymi może trochę stracić sens. Ale to sprawa do przemyślenia.
- Struts lub Struts2, całkiem inne podejście niż Wicketa i JSF, więc do porównania jak znalazł, bo pewnie pojawią się ciekawe wnioski odnośnie różnic między filozofią komponentowo-obiektową, a requestowo-akcyjną.
- i inne: GWT - od Google, więc nie może być złe :), Spring MVC, Tapestry 5 (fajny, choć, gdy był w fazie beta to mocno się do niego zraziłem), Stripes (trochę starszy framework i trochę podobny do Struts).
Jak widać opcji jest sporo, a czas nie jest nieograniczony, bo jednak im szybciej się z tym ogarnę, tym lepiej :) Dlatego temat zostaje do przemyślenia, dopóki nie uporam się z aplikacją w Wicket. Wtedy będę musiał podjąć decyzję co dalej.
Po odwiedzinach u promotora doszła jeszcze jedna sprawa: doprecyzowanie celu pracy tak, aby był bardziej magisterski niż inżynierski. Ma to być rozwiązanie jakiegoś bardziej ogólnego problemu i wyciągnięcie bardziej ogólnych wniosków, a nie tylko napisanie kilku aplikacji w różnych frameworkach. Sugestia promotora jest taka, żeby pójść następującym tropem:
- wielość rozwiązań (bibliotek) dla aplikacji webowych dla małych i średnich firm
- problemy z wyborem odpowiedniej drogi
- różnorodność aplikacji, ale spora część wymagań się powtarza
- dobranie rozwiązania nie pod kątem tego, co znają programiści, ale pod kątem tego, co najlepiej spełni wymagania klienta
- nie ma rozwiązań idealnych, ale są takie, które najlepiej sprawdzają się przy wymaganiach, na które klient kładzie największy nacisk.
Jak widać mam co robić, więc wakacje zapowiadają się pracowicie :) Niestety temat SCWCD na razie został odłożony na półkę, głównie z powodu nacisków promotora na szybsze ogarnięcie pracy dyplomowej. Ale na pewno do niego wrócę, bo mam dość jasno nakreślony plan ścieżki rozwoju jako programista i certyfikat chcę zrobić. Postaram się też na bieżąco relacjonować postępy w pisaniu pracy, a że poznam sporo nowych rzeczy to i tematów do wpisów też mam nadzieję nie zabraknie. Stay tuned :)
Bardzo interesuje mnie efekt tej pracy, niekoniecznie całościowy, ale przynajmniej zgrubny. Jestem początkujący w Javie, a muszę rozpocząć duży projekt - wyświetlanie zestawień (raportów) z dużej bazy danych i nie wiem jaki framework byłby najlepszy do tego. Próbowałem Visual JSF, ale przy większych zestawieniach bardzo muli. Masz może jakieś sugestie?
OdpowiedzUsuńNiestety na efekty zgrubnego porównania trzeba jeszcze poczekać, bo aplikacja w Wicket jest już gotowa, a teraz "robi się" w GWT, potem być może JSF, ale bardziej z obowiązku niż ze szczerej chęci zabawy tym frameworkiem.
OdpowiedzUsuńZe swojej strony moge polecić Wicketa, bo cały czas się nim zachwycam i nigdy (zrobiłem w nim już 3 spore projekty, teraz robię czwarty) mnie nie zirytował swoim działaniem.
Są do niego dwie dobre książki, masa tutoriali i how-to w sieci. Dzięki temu, że każdy komponent (link, button na stronie, itp.) jest klasą javową, wszystko możesz customizować, rozszerzać, budować swoje komponenty w oparciu o kod już istniejących. Pełna wolność :)
Jeśli będziesz budował raporty to na pewno okaże się, że sporą cześć logiki (panele czy wykresy) można ponownie wykorzystać w wielu miejscach aplikacji, a Wicket mocno ułatwia budowanie własnych komponentów, które można wstawiać na stronę za pomocą jednej linijki kodu.
Dodatkowo warstwę prezentacji robisz w czystym html-u, prawie bez żadnych wicketowych tagów (w przeciwieństwie do JSF, gdzie z tagami jest masakra), więc nie trzeba kombinować dlaczego coś na stronie nie wygenerowało się zgodnie z założeniami, bo htmla każdy raczej zna.
Wydajność i szybkość? Z tym jest tak jak przy każdym innym frameworku: jeśli umiesz korzystać i robisz to świadomie to da się osiągnąć dobre rezultaty, jeśli robisz to na "łapu-capu" bez interesowania się jak to wszystko działa, mogą pojawić się problemy.
Wicket jest stanowy, czyli (w uproszczeniu) sporo danych może być trzymane w sesji. Jeśli na stronie masz 1000 obiektów z bazy danych, które dodatkowo załadowały sobie jakieś kolekcje obiektów zależnych i nie zwrócisz uwagi na to, w jaki sposób obsłużyć tąką sytuację, całość wyląduje Ci w sesji, co przy większej ilości użytkowników może być niefajne :)
Oczywićie bardzo łatwo można uniknąć takich problemów, ale trzeba sobie z nich zdawać sprawę.
Podobno Tapestry 5 jest szybkie, ale tam twórca trochę za często zmienia kierunek, w którym cały framework zmierza i ja bym się trochę bał w poważnym projekcie na Tapestry oprzeć.
Jeśli masz pobierać informacje z dużej bazy danych, to szybkość warstwy prezentacji nie musi być kluczowa, bo wolno może działać już samo pobieranie danych z bazy (niezoptymalizowane albo skomplikowane zapytania), ale to wszystko to już sprawa indywidualna w każdym projekcie.
Podsumowując: Wicket, bo daje radość tworzenia i dużo można z niego wykrzesać bez korzystania z jakichś skomplikowanych hacków :)
W razie czego służę pomocą (tdziurko na gmail) albo GG: 2579522.