Почему я должен использовать Scala / Lift над Java / Spring? [закрытый]

должен сказать, что я категорически не согласен с ответом Дэна Ларока.

подъем не монолитен. Он составлен на дискретных элементах. Он не игнорирует элементы J/EE, он поддерживает подобные JNDI, JTA, JPA и т. д. Тот факт, что вы не вынуждены использовать эти элементы J/EE, является сильным признаком модульной конструкции лифта.

• философия взгляда лифта - " пусть разработчик решает."Lift предлагает механизм шаблонов, который не допускает никакой логики код в представлении, механизм представления, основанный на выполнении кода Scala и XML-литералов Scala, и механизм представления, основанный на Scalate. Если вы выбираете механизм шаблонов XML, то вы выбираете, сколько, если таковые имеются, наценка принадлежит в вашей бизнес-логике. Разделение представления Lift сильнее, чем все, что может предложить Spring, потому что вы не можете выразить бизнес-логику в XML-шаблонах Lift.
• объект лифта philosophy философия настойчивости " пусть разработчик решает." Lift имеет Mapper, который является реляционным mapper объекта стиля ActiveRecord. Он выполняет работу для небольших проектов. Поднимите поддержку JPA. Lift имеет абстракцию записи, которая поддерживает перемещение объектов в реляционные базы данных и из них, в магазины NoSQL и из них (Lift включает встроенную поддержку CouchDB и MongoDB, но слои адаптера-это несколько сотен строк кода, поэтому, если вы хотите Cassandra или что-то еще, это не много работы, чтобы получить его.) В принципе, Lift the Web Framework не имеет зависимость от того, как объекты материализуются в сеанс. Кроме того, циклы сеанса и запроса открыты так, что вставка крючков транзакций в цикл запроса/ответа проста.
• философия лифта: "команда сервера должна знать один язык, а не несколько языков."Это означает, что настройка выполняется через Scala. Это означает, что нам не нужно было реализовывать 40% языковых конструкций Java в синтаксисе XML для создания гибких параметров конфигурации. Это значит, что синтаксис и тип компилятора-проверяет данные конфигурации, чтобы вы не получали странный синтаксический анализ XML или неправильные данные во время выполнения. In означает, что вам не обязательно иметь IDE, которые понимают особенности аннотаций, которые вы используете, на основе используемой библиотеки.
• да, документация лифта не является его сильной стороной.

С выше сказанным, позвольте мне поговорить о философии дизайна лифта.

я писал Веб-Фреймворк Манифест прежде чем я начал писать Lift. В большей степени, и в большей степени, чем это верно для любой другой веб-структуры, о которой я знаю, Lift отвечает этим целям.

Lift в своем ядре стремится абстрагировать цикл HTTP-запроса/ответа, а не размещать обертки объектов вокруг HTTP-запроса. На практическом уровне это означает, что большинство любых действий, которые может предпринять пользователь (отправка элементов формы,выполнение Ajax и т. д.) представлен идентификатором GUID в браузере и функция на сервере. Когда GUID представлен как часть HTTP-запроса, функция применяется (вызывается) с предоставленными параметрами. Поскольку GUID трудно предсказать и специфичны для сеанса, атаки воспроизведения и многие атаки изменения параметров намного сложнее с лифтом, чем большинство других веб-фреймворков, включая Spring. Это также означает, что разработчики более продуктивны, потому что они фокусируются на действиях пользователя и бизнес-логике, связанной с действиями пользователя, а чем сантехника упаковки и распаковки HTTP-запроса. Например, код для принятия или отклонения запроса друга FourSquare:

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

Это очень просто. Потому что friendRequest в рамки, когда создается функция, функция закрывает за рамки... нет необходимости раскрывать первичный ключ запроса друга или делать что-либо еще... просто определите текст кнопки (он может быть локализован или его можно вытащить из шаблона XHTML или его можно вытащить из локализованного шаблона) и функции для выполнения при нажатии кнопки. Lift заботится о назначении GUID, настройке вызова Ajax (через jQuery или YUI, и да, вы можете добавить свою любимую библиотеку JavaScript), выполнении автоматических попыток с отступлениями, избежании голода соединения путем очереди Ajax-запросов и т. д.

так, одна большая разница между подъемом и весной что общее соображение подъема GUID связанного с функцией имеет двойное преимущество гораздо лучшее обеспеченности и гораздо лучше производительность разработчиков. Ассоциация функции GUID -> доказывала очень durable... та же конструкция работает для обычных форм, ajax, comet, многостраничных мастеров и т. д.

следующая часть ядра подъема держит абстракции высокого уровня вокруг как можно дольше. На стороне создания страницы это означает создание страницы как элементов XHTML и сохранение страницы как XHTML до непосредственно перед потоковой передачей ответа. Преимущества сопротивление к перекрестному месту ошибки сценариев, возможность перемещения тегов CSS в начало и скриптов в нижнюю часть страницы после того, как страница была составлена, и возможность переписать страницу на основе целевого браузера. На стороне ввода URL-адреса могут быть переписаны для извлечения параметров (как параметров запроса, так и параметров пути) типобезопасным образом, высокий уровень, проверенные данные безопасности доступны для обработки очень рано в цикле запроса. Например, вот как определить обслуживание REST запрос:

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

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

С этими 2 частями сердечника, подъем имеет большущее преимущество оперируя понятиями обеспеченности. К дайте вам представление о величине безопасности лифта, которая не мешает функциям,Расмус Lerdorg кто сделал безопасность для Yahoo! пришлось это сказать про FourSquare (один из постеров лифта-детский сайт):

четыре звезды на сайт @foursquare-1st через некоторое время я хорошо рассмотрел, что у меня не было ни одной проблемы с безопасностью (которую я мог найти) -- http://twitter.com/rasmus/status/5929904263

в то время, У FourSquare был один инженер, работающий над кодом (не то, что @harryh не супер-гений), и его основным направлением было переписывание PHP-версии FourSquare, справляясь с еженедельным удвоением трафика.

последняя часть фокуса безопасности лифта-Карта сайта. Это единый контроль доступа, навигация по сайту и система меню. Разработчик определяет правила управления доступом для каждой страницы с помощью кода Scala (например,If(User.loggedIn _) или If(User.superUser _)) и эти правила контроля доступа применяются перед любой страницей начинается отрисовка. Это очень похоже на Spring Security, за исключением того, что он запечен с начала проекта, и правила управления доступом унифицированы с остальной частью приложения, поэтому вам не нужно иметь процесс обновления правил безопасности в XML при изменении URL-адресов или методов, которые вычисляют изменение управления доступом.

суммировать до сих пор, общее соображение конструкции подъема дает вам преимущества испеченный в контроле допуска, сопротивлении к обеспеченности верхней части 10 OWASP уязвимости, гораздо лучшая поддержка Ajax и гораздо более высокая производительность разработчиков, чем Spring.

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

Lift-это своего рода веб-фреймворк, который позволяет разработчику сосредоточьтесь на общей картине. Сильный, выразительный печатать и более высокий уровень особенности как встроенная поддержка кометы позволяет вам сосредоточиться на инновациях вместо водопровод. Построение богатого, реального времени веб-приложение, как Novell Pulse требует структуры с силой Поднимите под одеялом.

Итак, Lift-это не просто еще одна структура MVC. Это структура, за которой стоят некоторые основные принципы дизайна, которые очень хорошо созрели. Это структура, которая дает двойные преимущества безопасности и производительности разработчиков. Lift-это структура, которая построена в слоях и дает разработчику правильный выбор, основанный на их потребностях... выбор для генерации представления, выбор для сохранения и т. д.

Scala и Lift дают разработчикам гораздо лучший опыт, чем смесь XML, аннотаций и других идиом, которые составляют Spring.

Я бы рекомендовал вам проверить Play framework, он имеет некоторые очень интересные идеи и поддерживает разработку на Java и Scala

просто для удовольствия. И ради изучения новых подходов к программированию.

Я сильно изучил использование Lift для недавнего веб-проекта, не будучи большим поклонником Spring MVC. Я не использовал последние версии, но более ранние версии Spring MVC заставили вас прыгать через множество обручей, чтобы запустить веб-приложение. Я почти продался на лифте, пока не увидел, что лифт может быть очень зависимым от сеанса и потребует "липких сеансов" для правильной работы. Выдержка из http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

пока есть стандартная сессия технология репликации можно еще кластер приложений, используя "липкие сессии". Это МЭС, что все запросы, относящиеся к сеансу HTTP, должны обрабатываться одинаково узел кластера

поэтому, как только требуется сеанс, пользователь должен быть привязан к этому узлу. Это создает потребность для толковейшей балансировки нагрузки и влияет на масштабирование, что помешало Lift быть решением в моем случае. Я закончил выбор http://www.playframework.org/ и были очень довольны. Играть стабильно и надежно и очень легко работать.

Я не приходите, чтобы поднять и Scala с фона Java, так что это не из личного опыта, но я знаю, что многие разработчики лифтов считают Scala гораздо более сжатым и эффективным языком, чем Java.

расширение ваших знаний всегда стоит усилий :) я только начал изучать Scala, это влияет на то, как я пишу нормальную Java, и я могу сказать, что это было очень полезно до сих пор.

Я ненавижу полностью бросить ваш мир за цикл. Но вы можете использовать Scala, Java, Lift, Spring в одном приложении и это не проблема.

давайте рассмотрим, что вы хотите написать приложение. Если вы достойный разработчик, приложение уже должно быть построено в вашем уме. Следующий шаг-узнать, как это работает с помощью кода. Для этого вам нужно передать воображаемое приложение через функцию, которая переводит его в приложение реального мира. Эта функция является языком программирования. Так что

Real app = programming language (imagined app)

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

что касается меня, я медленно изучаю Scala и поднимаю и люблю его.

но главная проблема в том, что мы не можем сравнить весну с лифтом. Lift в основном используется как UI framework, а Spring - как di framework.
Если вы разрабатываете веб-приложение, которое имеет столько бэкэнда, вы можете использовать lift.
но если ваше развивающееся веб-приложение имеет некоторый бэкэнд серии, и вам определенно нужно перейти к весне.