2013-04-07 11 views
5

Staramy się wybrać ramy dla rozwoju naszego klienta dla aplikacji internetowej. To są kluczowe punkty dotyczące naszej aplikacji.Vaadin do tworzenia aplikacji internetowych - Niewiele wątpliwości

1) Aplikacja tekstowa, w której użytkownik wykonuje wiele czynności w kliencie.

2) Chcemy rozwijać przy użyciu technologii Java

3) usługi będą oferowane w chmurze.

4) Wymagane wsparcie dla urządzeń mobilnych.

5) Skalowalność jest również jednym z głównych problemów.

Przeszedłem przez wiele doc i informacji wraz z tym filmem http://twit.tv/show/floss-weekly/187 online i teraz pozostało Vaadin i zwykły GWT. Mam małe doświadczenie w rozwoju z GWT, ale nie w Vaadin (napisałem kilka przykładowych programów tylko w Vaadin). Proszę, pomóż mi w zrozumieniu kilku rzeczy.

1) Czy muszę napisać nowy widżet w języku Vaadin, jak łatwo lub trudno to osiągnąć?

2) Czy są jakieś oczywiste problemy z widżetami lub koncepcjami Vaadin, które mogą blokować jakąkolwiek aplikację?

3) Jeśli jutro zdecydujemy się powrócić do GWT, jest to możliwe, biorąc pod uwagę, że Vaadin działa ze wszystkimi kodami logicznymi serwera?

4) Czy metoda Vaadin przechodzi na serwer za każdym razem, gdy dotyczą one aplikacji wdrażanych w chmurze?

5) Ostatni, ale najważniejszy, jak jest wsparcie forum i przyszłego dewelopera?

Wielkie dzięki. Zauważ, że przeszedłem wiele artykułów i linków na temat tych dyskusji, ale czuję, że dobrze jest wiedzieć od faceta, który ma prawdziwe doświadczenie w tych rzeczach co najmniej od jakiegoś czasu. Dzięki jeszcze raz.

Odpowiedz

1

jeśli chcesz przyszłego dewelopera, idź z jsf, szczerze. To nie jest najlepszy wybór, ale będziesz przynajmniej podatny na umierające frameworki.

W naszym projekcie muszę użyć Vaadina, nie zdecydowałbym tak. Wolę ZK (http://www.zkoss.org/) lub GWT.

Odnośnie Państwa pytań, o ile mogę na nie odpowiedzieć.

  1. Relatywnie łatwe, takie jak Swing. Rozszerzasz CustomComponent i gotowe.
  2. Wydajność. Podczas programowania mamy problemy z wydajnością i problemy. Architektura musiała być wielokrotnie przemyślana z powodu specyfikacji VAADIN. W połączeniu z JPA, dla mnie praca z nią nie jest przyjemnością.
  3. Trudno powiedzieć. Oczywiście czytasz wszędzie o MVC, luźnym sprzęcie itp. Ale osobiście uważam, że zawsze masz jakieś korzenie ze swojego GUI framework, które wpływają na jakiś kod poniżej. Nie możesz po prostu zmienić struktury jako plug'n play. Nie znam szczegółów, ale prawdopodobnie styl życia jest już inny niż w innych frameworkach. Zatem implementacja Vaadin do komunikacji z bazą danych, na przykład podczas korzystania z FormFactory, wpłynie na twoją warstwę utrwalania, którą będziesz musiał dostosować podczas korzystania z innej struktury.Po prostu dzięki wdrożonej strategii.
  4. Nie mam tutaj żadnego doświadczenia.
  5. Vaadin jest duży w społeczności i wygląda na to, że wiele osób go używa. Doświadczyłem, że zespół Vaadina robi wysiłek w celu propagowania struktury, a także jest tam, aby odpowiedzieć na pytania i pomóc, gdzie tylko może. Doceniam to. Dokumentacja jest naprawdę dobra.

Osobiście uważam, że będziesz musiał głęboko przemyśleć ramy i czy to pasuje do twoich potrzeb. Przed wyborem dla wielkiego ramach myśleć Abou, jeśli chcesz - programowanie po stronie serwera (ZK, Vaadin,) - serwer i klient (GWT) - używając języka znaczników i logiki (JSF)

co będzie konfigurację środowiska, np. serwer aplikacji, bazę danych itp.?

Mimo że Vaadin to dobry produkt, nie użyłbym go, gdybym mógł wybrać.

Ciao

+0

JSF jest umierającym tech - http://www.google.com/trends/explore?hl=pl#q=jsf&cmpt=q – SSR

1

myślę, że należy podjąć tę decyzję w zależności od architektury każdego, ponieważ jest to punkt, w którym najbardziej różnią.

Vaadin jest zgodny z Half-Object Pattern i dlatego jest bardziej porównywalny do Eclipse RAP (i ZK) niż do GWT. Zasadniczo masz aplikację serwera i kontrolujesz ją z poziomu przeglądarki. Pomyśl o prostym przycisku, jego stan jest wstrzymany na serwerze, a w przeglądarce widzisz jego reprezentację. Za każdym razem, gdy stan przycisku zmienia się, musi on komunikować się z serwerem, aby zaktualizować jego stan. Tak jest w przypadku każdego widżetu, jaki masz.

Muszę powiedzieć, że nie mam dużego doświadczenia z Vaadinem lub RAP, ale wyobraź sobie, ile stanów twój serwer będzie musiał żonglować, gdy masz wiele widżetów i wielu użytkowników, którzy używają ich w tym samym czasie. To może nie być wielkim problemem w chmurze, ale może na tradycyjnym serwerze z ograniczonymi zasobami.

To powiedziawszy, można sobie wyobrazić, że takie podejście nie jest zbyt przyjazne dla urządzeń mobilnych. Każda zmiana stanu powoduje objazd serwera w obie strony, ale na urządzeniach przenośnych możesz mieć słabe połączenie lub nawet nie mieć go wcale. Tutaj zdecydowanie wolałbym zwykły GWT, ponieważ może on działać całkowicie w przeglądarce i jest również użyteczny "offline".

Twoje drugie pytanie dotyczyło widżetów. To prawda, że ​​GWT nie dostarcza tylu widgetów co Vaadin, ale istnieją dobre biblioteki Widget, które uzupełniają widżety GWT. Problem polega na tym, że nie możesz zacząć od Vaadin i zdecydować później, aby powrócić do GWT, ponieważ widżetów napisanych w Vaadin nie można używać w zwykłym GWT. Ale w Vaadin można korzystać z aplikacji GWT Widgets i samodzielnie napisanych widżetów.

Proponuję zacząć od zwykłego GWT, napisać własne widżety za pomocą UiBinder, jest to bardzo łatwe. Jeśli uważasz, że chciałbyś użyć bardziej złożonych widgetów, przejrzyj biblioteki widgetów, takie jak GWT-Bootstrap lub Sencha GXT, grają one bardzo ładnie z prostym GWT.

+0

dzięki, że poszliśmy z gładkim GWT również w naszym przypadku. dzięki za czas ur – LPD

Powiązane problemy