Сравнение Lift с Play2

Я использовал play2 раньше с java. Это было немного похоже на шаблон, особенно если вы использовали акку с java. Но это не ошибка структуры.

Вчера я прочитал "Scala для нетерпеливого", и мне очень нравится этот язык.

Теперь я посмотрел на обе платформы Lift 2.5 и Play 2.0.3. Я думаю, что у лифта есть более высокая кривая обучения, и я не мог просто сделать что-то с лифтом. Это не для меня. Из того, что я увидел, у Lift очень красивый и чистый дизайн.

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

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

  • Для безопасности я не думаю, что это работа с каркасом.

  • Stateless/Stateful: Трудно сказать, где основные отличия. Я знаю только, что игра имеет также состояние, если вы используете веб-сокеты.

  • Обе фреймворки могут компилироваться после нажатия F5. Мне очень нравится эта функция.

  • Обе структуры используют sbt

  • Подъем с авторизацией, но я думаю, что есть плагин play2 scala, который делает то же самое

  • Подъемник имеет ORM-карту для mongoDB. Поскольку я хочу использовать noSQL, это выглядит более чистым для меня. (Снова не так много опыта) Изменить. В программе play2 https://github.com/leon/play-salat

  • Async - Play 2 использует Akka. Не знаю, что использует лифт, но у них также есть что-то подобное.

  • Поднимите суда с поддержкой CSRF. Play2 имеет модуль для CSRF, но это добавляет шаблон к вашему коду.

  • Аутентификация без аутентификации, похоже, имеет некоторые уязвимости безопасности. Оба фреймворка имеют аутентификацию с учетом состояния. (play2 stateful/stateeless, lift stateful)

  • Каковы сильные стороны каждой структуры?

ОТВЕТЫ

Ответ 1

Проводя это, проведя неделю или две с Лифтом, на самом деле служить кому-либо. Тем не менее, я хочу потратить некоторое время на исправление некоторые ошибки и неправильные представления.

  • Для безопасности я не думаю, что это работа с каркасом.

Ты мертв. Безопасность - это основа работы. Очень важно, чтобы безопасность выполняется по умолчанию, а не полагается на каждого разработчика, чтобы понимать каждый уязвимости безопасности и убедитесь, что каждая строка кода учитывает это.

Все, что нам нужно сделать, это посмотреть, что случилось с GitHub чтобы понять, что даже лучшие кодеры, использующие хорошо известные технологии может сделать критическую ошибку.

Подъем обеспечивает надежный защитный слой сверху, поэтому по умолчанию нет XSS, CSRF и т.д. но разработчик может копать настолько глубоко, насколько он хочет HTTP-запрос и сделка с байтами на проводе.

  • Без гражданства/состояния: трудно сказать, где основные отличия. Я знаю только, что игра имеет также состояние, если вы используете веб-сокеты.

В лифте очень ясно, где вам нужно состояние, а где нет. Лифт может поддерживать безстоящие, частично с точки зрения состояния и полностью работоспособные приложения. На странице за страницей и запрос по запросу, приложение "Лифт" может быть с сохранением состояния или без гражданства (например, в Foursquare, страницы места размещения являются апатридами для поисковые системы, но с сохранением состояния для браузеров, которые вошли в систему.) Для подробнее о проектных решениях вокруг штата, см. Подъем, состояние и масштабирование.

  • Обе структуры используют sbt

В лифте используются Maven, sbt, Buildr и даже Ant. Подъемник не зависит от условий сборки и о среде развертывания (Java EE container, Netty, что угодно). Это важно потому что это облегчает интеграцию с остальной средой.

  • Подъем с авторизацией, но я думаю, что есть плагин play2 scala, который делает то же самое

Лифтинг существует уже более 5 лет и имеет множество модулей и вещей для него. Веб-каркас Lift (в отличие от модулей) не зависит от стойкости, аутентификации и т.д., Поэтому вы можете использовать что-либо с лифтом.

  • Async - Play 2 использует Akka. Не знаю, что использует лифт, но у них также есть что-то подобное.

Подъем имеет поддержку Async более 5 лет. Он запек в каркасе. Подъем поддержки Comet лучший из любых веб-фреймворков, потому что, среди прочего, он мультиплексирует все "push" запросы на странице по одному запросу к серверу, который позволяет избежать голода подключения. Как Lift делает асинхронный процесс менее важно, потому что одна из основных философий с Лифтом заключается в том, что мы удаляем сантехника от разработчика, чтобы разработчик мог сосредоточиться на бизнес-логике.

Но для тех, кто ухаживает, у Lift есть самые лучшие и легкие весовые актеры любых фреймворков в Scala -land. Мы были первыми, кто оторвался от библиотеки scala Actor и работал проложить путь для разных библиотек Актера, которые позволили Акке и ScalaZ Актерам процветать.

  • Поднять суда с поддержкой CSRF. Play2 имеет модуль для CSRF, но это добавляет шаблон к вашему коду.

Это часть приверженности Лифт к безопасности. Он важный.

  • Аутентификация без аутентификации, похоже, имеет некоторые уязвимости безопасности. Оба фреймворка имеют аутентификацию с учетом состояния. (play2 stateful/stateeless, lift stateful)

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

Кроме того, как я указал в столбце "Лифт", "Состояние" и "Масштабирование", как сериализовать состояние безопасным, масштабируемым, исполнительным образом (потому что практически каждый запрос в Интернете приложение, которое распознает конкретных пользователей, является состоянием) должно быть сделано в предсказуемом, безопасный способ для платформы с разумными переопределениями для разработчиков.

Замечание о разделении

Игра очень похожа на Rails: быстро получить сайт, сбитый вместе, и он основанный на MVC, поэтому многие разработчики это понимают. Но играть не хватает глубину и широту Rails (сообщество, плагины, опыт, талант и т.д.) Если вы хотите быстро, легко MVC, затем перейдите с Rails и JRuby и напишите back end в scala (они работают вместе необыкновенно хорошо.)

Подъем - это другой зверь. Там есть значительная кривая отладки (перестаньте думать MVC и сначала задумайтесь о пользовательском опыте, который перетекает в бизнес-логику.) Но как только вы поднимаетесь на кривую развязки, сайты Lift более безопасны, высоко масштабируемым, супер-интерактивным и намного легче поддерживать с течением времени.

Ответ 2

Чтобы узнать, что можно сделать с Play (это может быть круто), посмотрите Консоль TypeSafe

Чтобы быстро перейти с помощью Lift, используйте шаблонный проект.

Для примера использования Mongo with Play просмотрите Factile.

В общем, я не думаю, что вы поедете неправильно с лифтом или игрой. Оба являются активными проектами, с хорошими сообществами и хорошей поддержкой от авторов. Это действительно зависит от вашей бизнес-проблемы. Если поддержка инструмента важна для вас, тогда вы можете захотеть взглянуть на использование Play (она хорошо поддерживается в IntelliJ Idea).

Обратите внимание, что Play, являясь частью стека технологий TypeSafe, будет иметь до последних версий Scala, поэтому, если использовать функции Scala 2.10 важны для вас, тогда вы можете захотеть сохранить это в разум. В настоящий момент лифт использует Scala 2.9.2, что тоже хорошо.

В моем текущем проекте я использую lift-mapper для ORM (It great and rock solid), с Spray для REST (что просто потрясающе). Такой подход полностью избегает фреймворков, но зависит от того, что вы хотите сделать. Рамки довольно часто идут.