Оценка Ваадина: сильные и слабые стороны

1. События низкого уровня
2. Компоненты и их распределение
3. Событийно-управляемая модель
4. Сильные стороны
5. Недостатки
6. Нет модных графических интерфейсов
7. SEO
8. Резюме - Минусы

Vaadin - это зрелая веб-платформа для разработки многофункциональных интернет-приложений. Создание веб-интерфейса с Vaadin похоже на разработку настольного приложения, которое отлично, удобно и быстро. Однако бывают ситуации, когда Ваадин не подходит. В этой статье мы рассмотрим архитектуру Vaadin и укажем на ее сильные и слабые стороны. Давайте начнем.

Vaadin позволяет создавать многофункциональные интернет-приложения (RIA). RIA стараются быть такими же отзывчивыми и интерактивными, как настольные приложения (меньше перезагрузок страницы; обмениваться частями страницы с помощью AJAX и DOM-манипуляций). Vaadin делает еще один шаг вперед, создав одностраничное веб-приложение (SPA) (без перезагрузки страницы).

Единственный язык программирования, который вам нужен - это Java. Нет необходимости в веб-интерфейсных технологиях, таких как JavaScript или HTML. Чтобы получить представление о том, как вы программируете графический интерфейс в Vaadin, взгляните на пример адресной книги на Vaadin.org:

Прежде всего, давайте посмотрим на архитектуру Vaadin. Это важно для последующей оценки.

События низкого уровня

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

События низкого уровня асинхронно обмениваются между клиентом и сервером

Клиент не говорит «удалить этот контакт» серверу (семантическое событие). Вместо этого он просто заявляет «кнопка 74 была нажата» (событие низкого уровня). Сообщение содержит только низкоуровневую информацию о взаимодействии с пользователем. В этом сообщении нет логики приложения. Только сервер знает, что означает нажатие кнопки семантически. Вся логика приложения находится исключительно на стороне сервера.

Компоненты и их распределение

Следующий рисунок иллюстрирует компоненты Vaadin и их распределение:

Архитектура Ваадина: распределение компонентов

Клиентский движок работает в браузере и написан на JavaScript. Он отображает пользовательский интерфейс, получает взаимодействие с пользователем и отправляет их как события на сервер. Браузер служит только в качестве так называемой «платформы тонкого клиента». Ему нужно только визуализировать пользовательский интерфейс и сообщить о событиях низкого уровня на сервер. Между клиентом и сервером отсутствует связь между приложениями. Это является преимуществом, поскольку логика приложения не разбросана по клиенту и серверу.

Server-Side Framework содержит логику пользовательского интерфейса и состояние каждого клиента. Вот где работает логика приложения. Каждый компонент на стороне сервера (например, Button, TextField, Table) имеет аналог на стороне клиента, «виджет». Этот виджет является представлением компонента на стороне клиента.

Разработчик должен только реализовать логику пользовательского интерфейса и серверную часть. Все до этого слоя прозрачно для разработчика. Ему не нужно заботиться о веб-технологиях (HTML, JavaScript) или о взаимодействии клиент-сервер (HTTP, AJAX, JSON-сериализация, сеансы). Он использует только Java API компонентов.

Событийно-управляемая модель

На следующем рисунке показана обработка событий в Vaadin.

Обработка событий в Ваадине

1. Пользователь делает что-то в пользовательском интерфейсе, например, нажав кнопку. Это вызывает событие, которое потребляется соответствующим виджетом (кнопкой) в клиентской машине.
2. Это событие сериализуется в JSON и асинхронно отправляется сервлету Vaadin, работающему на сервере. Сервлет получает запрос клиента и отправляет событие в соответствующий компонент пользовательского интерфейса. Это возможно, потому что каждое событие (виджета) связано с компонентом и доставляется в прослушиватель событий, определенный в логике пользовательского интерфейса.
3. Логика пользовательского интерфейса (реализованная разработчиком) обрабатывает событие и изменяет компоненты пользовательского интерфейса на стороне сервера (например, вставка текста в текстовое поле, отключение кнопки или фильтрация таблицы).
4. Сервлет передает эти изменения пользовательского интерфейса в браузер, отправляя ответ обратно в браузер. Клиентский движок в браузере получает ответ.
5. Клиентский движок изменяет страницу в браузере, манипулируя DOM. Обновленный пользовательский интерфейс представлен пользователю.

Сильные стороны

По моему опыту, Vaadin позволяет вам создавать интерактивные и адаптивные веб-приложения с высоким уровнем комфорта и скоростью разработки. Он поставляется с мощным, простым в использовании набор компонентов , Другим практическим преимуществом является подход к программированию в моноглоте и использование хорошо известного императивного стиля программирования GUI. Если ваша команда разработчиков уже знакома с Java и уже имеет опыт программирования GUI на Swing, SWT / JFace или JavaFX, они сразу же станут продуктивными. Та же концепция, тот же язык. Они не обязаны изучать JavaScript, несколько библиотек JavaScript (jQuery, jQuery UI, AngularJS и т. Д.), Веб-методы (AJAX, сеансы, файлы cookie, специфичная для браузера обработка), протоколы и форматы (HTTP, WebSockets, JSON). Ваадин позаботится об этом. Тем не менее, полезно знать их.

Резюме - Плюсы:

• Быстрая разработка
• Плоская кривая обучения благодаря программированию моноглота (только Java)
• Разрабатывайте веб-приложение как настольное приложение.
  • Хорошо известная парадигма императивного пользовательского интерфейса
  • Специфичные для веб-сайтов вопросы прозрачны для разработчиков. Им не нужно учить их.
• Комплексный и сложный набор компонентов и механизм привязки данных.
• Действительно хорошая документация и активное сообщество

Недостатки

Масштабируемость

Одним из недостатков Vaadin является его плохая масштабируемость. Для лучшего понимания я сравниваю архитектуру Vaadin с архитектурой Thin Server.

Фреймворки презентаций на стороне сервера по сравнению с архитектурой тонких серверов

В архитектуре тонкого сервера логика и состояние пользовательского интерфейса расположены на клиенте. Вы используете библиотеки HTML и Java-Script, такие как AngularJS, для программирования элементов и логики пользовательского интерфейса. Сервер превращается в поставщика данных через веб-сервис REST. Вам не нужно много запросов, потому что вам нужно только запрашивать данные, а не логику пользовательского интерфейса. Этот подход достаточно хорошо масштабируется, поскольку состояние пользовательского интерфейса находится на клиенте (экономит память сервера), логика пользовательского интерфейса выполняется на клиенте (экономит использование процессора сервера), а вызовы службы REST могут быть легко кэшированы и отправлены с помощью балансировщика нагрузки. (Сообщения REST являются самоописательными; для их обработки на стороне сервера не требуется состояния). В целом, эта архитектура хорошо справляется с большим трафиком.

Это недопустимо для приложений на основе Vaadin, которые представляют собой среду представления на стороне сервера. Состояние и логика пользовательского интерфейса хранятся на сервере, и для каждого взаимодействия с пользователем на сервер должен быть отправлен запрос, чтобы клиент знал, как он должен реагировать. Это приводит к увеличению сетевого трафика и загруженности сервера. Более того, вы должны хранить состояние пользовательского интерфейса для каждого клиента. Если количество клиентов увеличилось, вам нужно больше серверной памяти для хранения состояний пользовательского интерфейса.

Тем не менее, я настоятельно рекомендую вам прочитать пост Масштабируются ли приложения Vaadin? , В нем говорится, что Vaadin может обрабатывать тысячи одновременно работающих пользователей . Я хотел бы подчеркнуть, что это огромное количество и должно быть достаточно для многих случаев использования. Для меня аргумент масштабируемости используется слишком часто и даже в тех случаях, когда подход на стороне сервера все еще способен справиться с нагрузкой. Но если вы создаете общедоступные веб-сайты, Vaadin не подходит, потому что он не может масштабироваться так же, как другие подходы - из-за его архитектуры.

« Vaadin никогда не был создан для массовых публичных веб-сайтов . Если вам нужна масштабируемость на уровне facebook, Vaadin - не лучший инструмент для этого. Но для чего-то меньшего Ваадин наглядно работает и работает хорошо ». Йенс Янссон, Ваадин. Источник: Масштабируются ли приложения Vaadin?

Нет модных графических интерфейсов

Ваадин очень быстро занимается созданием бизнес-приложений. «Бизнес-приложения» означает приложения, состоящие в основном из форм и таблиц. Однако, если вам нужен сложный и тяжелый пользовательский интерфейс (например, анимации и пользовательские функции пользовательского интерфейса), Vaadin не подходит, потому что тогда вам нужен детальный и прямой доступ к DOM , что не так просто с Vaadin. В этом случае подумайте о найме ниндзя JavaScript и создайте свой пользовательский интерфейс напрямую с помощью веб-интерфейсных технологий.

SEO

Поскольку Vaadin загружает контент асинхронно с помощью JavaScript по одному URL, SEO сложно. Есть трюки и библиотеки сделать ваш контент доступным для сканеров. Но они определенно требуют дополнительных усилий, и результат может оказаться не таким гибким, как вы того пожелаете. Если SEO является главным требованием для вас, Vaadin (или SPA в целом) не лучший выбор.

Резюме - Минусы

• Не масштабируется по сравнению с другими архитектурными подходами. Более высокая нагрузка на сеть и сервер (память, процессор).
• Не подходит для модных графических интерфейсов.
• SEO

Заключение

Прежде всего, мне нравится Ваадин и его идея. Vaadin облегчает разработку многофункциональных интернет-приложений с высокой производительностью и комфортом, используя исключительно Java. Чтобы решить, подходит ли Vaadin для вашего проекта, вы должны учитывать общие требования (ожидаемая нагрузка, целевое ранжирование в поисковых системах, требования пользовательского интерфейса)

Если вы сталкиваетесь с низкой или средней нагрузкой (например, для внутренних систем или внутренних приложений для выбранной группы пользователей), Vaadin идеально подходит. В этом случае вы можете извлечь выгоду из ускоренного развития, плоской кривой обучения и высокого уровня комфорта. Если ваша команда уже знакома с Java и императивным программированием GUI, преимущество Vaadin еще больше.

Наоборот, если вам приходится иметь дело с огромным количеством пользователей, важен рейтинг Google или у вас необычные требования к пользовательскому интерфейсу, Vaadin не подходит. Поэтому я бы не советовал строить интернет-магазин с Ваадином.

Похожие

Комментарии