Разница между Apache Tapestry и Apache Wicket

Некоторые важные отличия, как я их вижу:

• Tapestry использует полустатическую структуру страницы, где вы можете работать с условными выражениями и циклами для достижения динамического поведения. Калитка полностью динамична; вы можете загружать компоненты динамически, заменять их во время выполнения и т. д. Следствием этого является то, что Tapestry легче оптимизировать, а Wicket более гибок в использовании.
• Обе структуры примерно одинаково эффективны в исполнении, но Wicket полагается на хранилище на стороне сервера (по умолчанию текущая страница в сеансе и прошлые страницы в «кеше второго уровня», который по умолчанию является временным файлом в файловой системе). Если вас это беспокоит, подумайте о том, сколько одновременных сеансов вы ожидаете провести в часы пик, и рассчитайте, скажем, ~ 100 КБ на сеанс (что, вероятно, является высоким показателем). Это означает, что вы можете поддерживать примерно 20 тысяч одновременных сеансов для 2 ГБ. Скажите 15k, потому что вам нужна эта память и для других вещей. Конечно, недостатком хранения состояния является то, что оно будет хорошо работать только с привязкой к сеансу, так что это ограничение при использовании Wicket. Фреймворк предоставляет вам средства для реализации страниц без состояния, но если вы разрабатываете полностью приложения без состояния, вы можете рассмотреть другой фреймворк.
• Цель Wicket - максимально полно поддерживать статическую типизацию, тогда как Tapestry больше ориентирована на сохранение строк кода. Таким образом, с Tapestry ваша база кода, вероятно, меньше, что хорошо для обслуживания, а с Wicket вы много статически типизированы, что упрощает навигацию с помощью IDE и проверку с помощью компилятора, что также хорошо для обслуживания. Что сказать имхо обоим.

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

ПЕРЕСМОТРЕНО после изучения Гобелена 5.

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

Цель Tapestry 5 - сделать очень оптимизированную (для ЦП и памяти) компонентно-ориентированную веб-платформу.

По-настоящему большой ловушкой для меня были ответы "Wicket поддерживает компонент без сохранения состояния!" к аргументам «Калитка голодна до памяти». Хотя Wicket действительно поддерживает компоненты без сохранения состояния, они не являются «фокусом разработки Wicket». Например, ошибка в StatelessForm очень долго не исправлялась - см. StatelessForm - проблема с параметрами после сбоя проверки.

• IMHO использование Wicket немного проще, пока вы не собираетесь оптимизировать / настраивать параметры веб-приложения.
• IMHO Wicket сложнее изучать, если вы запрограммировали веб-приложения и хотите думать в терминах обработки запросов.
• Tapestry 5 автоматически перезагружает классы компонентов, как только вы их меняете. Обе структуры перезагружают разметку компонентов.
• Wicket заставляет разделение разметки / кода, Tapestry 5 просто дает вам эту возможность. Вы также можете использовать менее подробный синтаксис в Tapestry 5. Как всегда, эта свобода требует большей осторожности.
• Ядро Wicket легче отлаживать: пользовательские компоненты основаны на наследовании, а пользовательские компоненты Tapestry 5 основаны на аннотациях. С другой стороны, это может упростить переход к будущим версиям для Tapestry, чем для Wicket.

К сожалению, учебник по Tapestry 5 не подчеркивает, что пример кода Tapestry, такой как 't: loop source = "1..10" ... 'может быть плохой практикой. Поэтому следует приложить некоторые усилия для написания правил использования гобеленов / передовых практик, если ваша команда не очень мала.

Мои рекомендации:

• Используйте Wicket, если структура ваших страниц очень динамична и вы можете позволить себе потратить 10-200 Кбайт памяти HttpSession на пользователя (это приблизительные цифры).
• Используйте Tapestry 5 в тех случаях, когда вам нужно более эффективно использовать ресурсы

Вот довольно подробное сравнение из IBM Developer Works.

http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

Обновление: ссылка мертва, но вы можете найти страницу на http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

Я думаю, что Wicket - это более простой в использовании фреймворк.

Кроме того, Wicket позволяет перезагрузить класс через систему замены горячего кода вашей IDE. Это все, что требуется Wicket для запуска измененных версий классов текущего приложения. Для замены горячего кода применяются обычные ограничения, такие как необходимость работать в режиме отладки (Eclipse) и невозможность изменять структурные аспекты класса (например, имя класса, изменение сигнатур методов и т. Д.).

Мне не нравится модель программирования Tapestry, и я знаю многих разработчиков, покидающих Tapestry из-за слишком большого количества изменений и несовместимости в разработке. См .: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

Wicket - очень хороший веб-фреймворк. Лучшее из всего, что я знаю. Я использую его с версии 1.3 и всегда получаю то, что хочу. Wicket имеет отличную интеграцию со Spring - просто используйте аннотацию @SpringBean в своем коде, чтобы внедрить любой Spring bean-компонент в свои классы.

Попробуйте http://incubator.apache.org/click/. Это потрясающий веб-фреймворк на Java. Некоторые называют это «Калитка, сделанная правильно» ;-)

Как я уже сказал, когда официальной стабильной версией была 4.1:

Вы должны очень внимательно изучить историю разработки Tapestry, прежде чем приступить к ее использованию. Tapestry претерпела множество несовместимых обновлений, при этом поддержка более старых версий не продолжается. Исправления до 4.1 больше не обрабатываются в разумные сроки. На мой взгляд, это неприемлемо для официальной стабильной версии.

Обязательство использовать Tapestry 5 означает:

вы должны стать коммиттером; нужно идти в ногу со всеми новыми разработками, как можно быстрее отказываться от старых версий; поддерживайте стабильные версии самостоятельно.