Разница между Apache Tapestry и Apache Wicket - PullRequest
45 голосов
/ 18 марта 2009

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

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

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

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

Ответы [ 8 ]

41 голосов
/ 13 августа 2009

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

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

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

35 голосов
/ 18 марта 2009

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

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

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

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

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

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

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

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

Вот довольно подробное сравнение с 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

1 голос
/ 16 января 2010

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

1 голос
/ 18 июля 2009

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

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

0 голосов
/ 13 июня 2010

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

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

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

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

0 голосов
/ 16 января 2010

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

0 голосов
/ 23 марта 2009

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

...