Вопрос по архитектуре: GWT или Vaadin для создания настольного приложения?

Мы планируем создать программу чтения каналов в виде приложения для настольных компьютеров и iPad. Поскольку мы хотим иметь возможность показывать веб-сайты И запускать (наш собственный) JavaScript в этом приложении, мы подумали о доставке приложения в виде HTML / CSS / JavaScript, только что упакованного каким-либо элементом управления .NET или компонентом веб-браузера Cocoa Touch. Итак, наша задача - выяснить, какой фреймворк использовать для создания файлов HTML / CSS / JS для встраивания в приложение.

Для разработки HTML / CSS / JavaScript мы были бы счастливы использовать Vaadin, GWT или какой-нибудь другой фреймворк, так как с Java у нас намного лучше, чем с JS. После короткого мозгового штурма мы отдаем предпочтение Vaadin, так как компоненты пользовательского интерфейса очень хороши, но я боюсь, что большая часть тяжелой работы будет лежать на сервере, а не на клиенте (и это было бы не очень хорошо). Мы также хотели бы GWT, но компиляция Java в JS занимает много времени и требует дополнительных шагов, а также замедляет время разработки в прошлом при ее использовании.

Вопрос в том, какую среду разработки вы бы выбрали (учитывая, что вы хотели реализовать этот проект, и до сих пор вы в основном использовали Java) и почему? Если есть варианты лучше (List of Rich Client Frameworks), дайте мне знать.

Изменить: приложению время от времени необходимо будет взаимодействовать с нашим сервером (например, синхронизировать то, что было прочитано), но в основном оно должно получать сами xml-каналы. Поэтому я надеюсь, что большая часть сгенерированного кода может быть встроена в приложение, и наш сервер не требует большой активности.

Edit2: Мы (реалистично, даже если вы сомневаетесь) ожидаем не менее 10000 пользователей.


desktop-application vaadin wicket gwt ria
person Akku    schedule 10.03.2011    source источник

Ответы (3)


arrow_upward
7
arrow_downward

Основываясь на моем опыте работы с Vaadin, я бы пошел на это, но ваши требования отчасти предпочитают чистый GWT.

  • Ваадину нужен сервер и соединение с сервером. Если вы создаете в основном автономное настольное приложение, это можно решить, например, с помощью встроенной Jetty. (синхронизируйте с онлайн-сервисом только при необходимости), но для iPad вам нужно будет сразу подключиться к сети, чтобы запустить приложение Vaadin.
  • GWT полностью работает на стороне клиента, и вы можете создать приложение браузера JavaScript, которое подключается только при необходимости.

Поскольку Vaadin разрабатывается намного быстрее, вы можете сначала создать небольшую версию Vaadin и посмотреть, действительно ли это проблема на iPad.

С другой стороны, если вы можете сразу предположить, что вы подключитесь к сети, вы можете вообще пропустить установку локального сервера. Просто запустите приложение онлайн и реализуйте настольную версию, используя элементы управления браузером по умолчанию операционной системы (т. Е. Элемент управления .NET, который вы предложили). Тогда Ваадину легче.

person eeq    schedule 11.03.2011

arrow_upward
4
arrow_downward

Vaadin - это просто фреймворк на основе GWT, но он имеет две очень важные особенности:

  • не нужно запускать компилятор GWT. Это чистая java. Конечно, если не добавить надстройки, потому что тогда должен запускаться компилятор gwt.
  • вам не нужно писать коммуникационный код. Таким образом, вам не нужно решать проблемы DTO, несериализуемые сопоставления объектов и не нужно писать сервлеты.

Я использую Vaadin в своей работе в течение одного года, и у нас пока нет проблем с производительностью (настольное приложение с ~ 500 пользователями). IMO очень хорошее решение - использовать Vaadin только для пользовательского интерфейса, логика переходит к независимым bean-компонентам и соединяет эти два элемента с помощью Spring или Guice.

В этом случае вы должны использовать шаблон MVP и разработку, управляемую доменом.

  • Bussines beans - это объекты и логика предметной области, которые используют интерфейсы просмотра для отправки ответов.
  • Пользовательские компоненты Vaadin (могут расширять стандартные компоненты) реализуют интерфейсы просмотра.

Этот способ хорош, когда вы решите изменить движок пользовательского интерфейса, если Vaadin не для вас. Просто перепишите сопоставления guice / spring и напишите новые реализации интерфейсов представления.

person Koziołek    schedule 10.03.2011

arrow_upward
4
arrow_downward

Мои 3 цента:

Если вы решите использовать vaadin, вы получите выгоду от уже ХОРОШИХ компонентов. Поскольку вы не хотите писать (много) CSS, vaadin уже хорошо выглядит из коробки. Однако Vaadin - это фреймворк SERVERSIDE. Взаимодействие с пользовательским интерфейсом затронет серверную часть, даже если они не связаны с получением каких-либо данных (например, переход с одной вкладки на другую).

Если вы решите использовать GWT, вам придется хотя бы стилизовать приложение (это несложно). Существует также проблема длительного времени компиляции (но вы можете тестировать и отлаживать в размещенном режиме, который позволяет запускать приложение без компиляции, тогда вы компилируете только при развертывании). Основное преимущество gwt заключается в том, что вы управляете тем, что отправляется по сети. Для взаимодействий с пользовательским интерфейсом, которые не требуют получения данных из серверной части, он будет работать исключительно на стороне клиента. Вы, разработчик, определите, когда отправлять запрос на серверную часть. (Выполнение запросов RPC в GWT очень просто)

Надеюсь, это поможет вам принять решение.

person joshua    schedule 11.03.2011