Вопрос

Калитка Апачей ( http://wicket .apache.org/ ) и Гобелен Апачей ( http://wicket .apache.org/ ) являются оба компонента ориентированы на веб-фреймворкs - в отличие от фреймворков, основанных на действиях, таких как Stripes - от Apache Foundation.Оба позволяют вам создавать свое приложение из компонентов на Java. Они оба очень похожи на меня.

В чем различия между этими двумя фреймворками?Есть ли у кого-нибудь опыт в обоих случаях?В частности:

  • Какова их производительность, насколько можно настроить обработку состояний, могут ли они использоваться без состояния?
  • В чем разница в их компонентной модели?
  • Что бы вы выбрали, для каких приложений?
  • Как они интегрируются с Guice, Spring, JSR 299?

Редактировать:Я прочитал документацию для обоих, и я использовал оба.Ответы на эти вопросы можно получить не из чтения документации, а из опыта их использования в течение некоторого времени, напримеркак использовать Wicket в режиме без состояния для высокопроизводительных сайтов.Спасибо.

Это было полезно?

Решение

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

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

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

Другие советы

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

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

Цель Гобелена 5 состоит в том, чтобы сделать очень оптимизирован (для процессора и памяти) компонентно-ориентированный веб-фреймворк.

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

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

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

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

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

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

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 означает:

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top