Каретка или Playframework?

Я совершенно не знаком с веб-разработкой Java, и я хотел бы выбрать хорошую веб-инфраструктуру Java для изучения. Я нашел некоторые действительно хорошие отголоски относительно Apache Wicket framework и Playframework. Я решил пойти на одного из них; но мне нужно выбрать; -)

Итак, что выбрать и почему?

ИЗМЕНИТЬ

Мои требования:

  • У меня был хороший опыт разработки с Django, поэтому подобная структура была бы отличной,
  • Мне нужна инфраструктура, которая может взаимодействовать с другими основными средствами Java (библиотеки, инструменты..etc), поэтому я могу воспользоваться тем, что действительно предлагает Java.

ОТВЕТЫ

Ответ 1

Wicket and Play - это два очень разных типа фреймворков.

Play - это структура MVC, которую вы, вероятно, почувствуете, знакомясь с Django. Как и Django, он предлагает больше, чем просто веб-биты, и обеспечивает структуру ORM на основе JPA, инструменты для строительных лесов и, возможно, намного больше (у меня нет практического опыта). На их сайте есть отличный учебник, и вы, вероятно, увидите сходство Django.

Wicket - это компонентно-ориентированная структура (как JSF и Tapestry) и в значительной степени фокусируется на объектно-ориентированном дизайне. Это также MVC, как таковой, но страницы обычно создаются путем создания автономных и многоразовых компонентов (View and Controller, pluggable Models). Эти компоненты могут быть расширены стандартным наследованием, а состав и разметка очень четко отделены от кода и легко модифицируются.

Wicket может управлять обратными вызовами событий и автоматически, так что вам не нужно думать о URL-адресах вообще, независимо от того, насколько сложна ваша страница. Быстрый пример нажатия кнопки, которая удаляется при нажатии (очень полезно):

  // In a page constructor
  add(new Link("link") {
        public void onClick() {
          setVisible(false);
        }
    });

Я хочу подчеркнуть, что вам не нужно использовать состояние на стороне сервера, и что вполне возможно использовать Wicket как "нормальную" структуру MVC, если вы хотите (и да, легко получить красивые URL-адреса),

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

Хотя я лично люблю Wicket, у меня есть подозрение, что вам, вероятно, будет лучше всего играть в Play. Ваш вопрос указывает, что вы хотите "Django" с доступом к Java-библиотекам, и в этом случае я думаю, что Play (или какой-либо другой Java MVC) является безопасным выбором. С другой стороны, возможно, вы использовали Django, потому что не знали, насколько невероятно мощная Wicket.;) Если вы дадите дополнительную информацию о своем проекте, мы сможем дать более квалифицированный ответ.

Как side- node: Поскольку Play не очень распространен (по крайней мере пока), я бы также рассмотрел Grails который имеет прочную коммерческую поддержку и еще больше готовых модулей.

Ответ 2

Играть! разработан, чтобы быть удобным для разработчиков, исходящих из языков сценариев, таких как Python и PHP. Он предоставляет собственную систему сборки и сценарии управления, как Rails или Django. Существующие инструменты сборки и инфраструктура (такие как репозитории Maven, обычно используемые для управления зависимостями в Java-land) не будут хорошо интегрироваться с Play.

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

Таким образом, существует довольно различие между двумя вариантами: Если вы можете понять, какой опыт принесет вам наибольшую выгоду, решение должно быть довольно ясным оттуда.

Ответ 3

Если ваша система предназначена только для веб-уровня, играйте! рамки очень подходят. But, если ваши модели данных предназначены не только для Интернета, а, возможно, exported as REST by Spring with CXF и используются GWT или другими веб-службами, и вы хотите убедиться, что согласованные состояния с веб-уровнем, Wicket (с Spring/hibernate) это хороший выбор.

Что-то, что мне не нравится в Play! является механизмом кэширования. Вы должны вручную называть/вставлять/извлекать/недействить/очищать кеш. Это сделает всю архитектуру ошибкой. В то время как калитка с Spring/JPA (hibernate)/ehcache (или другими поставщиками), вы можете определить постоянный уровень кэширования /dao для верхнего уровня (web/REST...), который не будет налагать несоответствия состояния.

Еще одно преимущество с калитки - это встроенная поддержка AJAX, поддерживаемая Java. Хотя эти состояния AJAX поддерживаются на стороне сервера (и, возможно, немного вяло), если вы не хотите изучать JavaScript, вы все равно можете создать "не очень-плохой" AJAX-страницу.

С игрой!, Если вы не знаете о JS и не хотите его изучать, не хотите манипулировать громоздкими DOM, вы можете создать только "средний" сайт. OTOH, если вы владеете JS/jQuery, вы можете выбрать Play!.

Ответ 4

Я использую PLAY! много и использовал Wicket для некоторой оценки. Мой опыт в том, что вам нужно написать намного больше кода, чтобы выполнить ту же работу с Wicket. У вас больше "косвенности" с Wicket. Я лично предпочитаю код, который имеет как можно меньше "церемонии", и это легко понять.

Игра! архитекторы также добавляют поддержку Scala для Play!, что я считаю отличной идеей, так как Scala полностью совместим с Java-кодом и библиотеками, но гораздо более продвинутым, чем Java.