Wicket или Playframework?
Преимуществом для наличия других языков для JVM является вполне то же как преимущество для наличия других языков для компьютера в целом: в то время как все полные Тьюрингом языки могут технически выполнить те же задачи, некоторые языки делают некоторые задачи легче, чем другие, в то время как другие языки делают другие задачи легче. Так как JVM - что-то, что у нас уже есть способность работать на всех (хорошо, почти все) компьютеры и много компьютеров, на самом деле уже иметь ее, мы можем получить "запись однажды, выполнить куда угодно" преимущество, но не требуя, чтобы каждый использовал Java.
Запись языка/компилятора для JVM не действительно отличается от записи той для реальной машины. Реальная разница - то, что необходимо скомпилировать в байт-код JVM вместо к исполняемому коду машины, но это - действительно незначительные различия в главной схеме вещей.
код Записи для языка кроме Java в JVM действительно не отличается от записи Java кроме, конечно, который Вы будете использовать различный язык. Вы скомпилируете использование компилятора, который кто-то пишет для него (снова, не очень отличающийся от компилятора C, существенно, и в значительной степени не отличающийся вообще от компилятора Java), и Вы закончите способность выполнить его точно так же, как Вы были бы скомпилированный код Java с тех пор, как только это находится в байт-коде, JVM не может сказать, из какого языка оно прибыло.
2 ответа
Играть! разработано так, чтобы быть удобным для разработчиков, использующих скриптовые языки, такие как Python и PHP. Он предоставляет свою собственную систему сборки и сценарии управления, что-то вроде Rails или Django. Существующие инструменты сборки и инфраструктура (например, репозитории Maven, обычно используемые для управления зависимостями в Java-land) не будут хорошо интегрироваться с Play.
Wicket будет более удобен для разработчиков, начинающих с разработки десктопов на Java. Он не предоставляет специального инструментария, поэтому его легче интегрировать в конкретный инструмент сборки, если у вас есть предпочтения (и в экосистеме Java доступно множество инструментов сборки, обеспечивающих такие вещи, как автоматический поиск зависимостей.)
Таким образом, между этими двумя вариантами есть определенная разница :) Если вы можете выяснить, какой опыт принесет вам наибольшую пользу, решение должно быть достаточно ясным.
Если ваша система предназначена только для веб-уровня, играйте! рамки очень подходят. But, если ваши модели данных предназначены не только для Интернета, возможно, exported as REST by Spring with CXF, и используются GWT или другими веб-службами, и вы хотите убедиться, что согласованные состояния с веб-уровнем, Wicket (с Spring / hibernate) является хороший выбор.
Что-то, что мне не нравится в Play! это механизм кеширования. Вы должны вручную назвать / вставить / получить / аннулировать / очистить кэш. Это сделает всю архитектуру подверженной ошибкам. Во время калитки с использованием Spring / JPA (hibernate) / ehcache (или других провайдеров) вы можете определить согласованный уровень кэширования / dao для верхнего уровня (web / REST ...), который не будет вызывать несоответствия состояний.
Еще одним преимуществом wicket является встроенная поддержка AJAX, поддерживаемая Java. Хотя эти состояния AJAX поддерживаются на стороне сервера (и, возможно, немного вяло), если вы не хотите изучать JavaScript, вы все равно можете создать «неплохую» страницу AJAX.
С помощью Играть! Если вы не знаете о JS и не хотите изучать его, не хотите манипулировать громоздкими DOM, вы можете создать только «средний» сайт. OTOH, если вы разбираетесь в JS / jQuery, вы можете выбрать Play! .