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

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

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

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

I пришел в Lift и Scala не на основе Java, так что это не из личного опыта, но я знаю, что многие разработчики Lift считают Scala гораздо более кратким и эффективным языком, чем Java.

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

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

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

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

Учитывая вышесказанное, позвольте мне немного поговорить о философии проектирования Lift.

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

В своей основе Lift стремится абстрагироваться от цикла HTTP-запрос/ответ, а не создавать объектные обертки вокруг HTTP-запроса. На практическом уровне это означает, что почти любое действие, которое может выполнить пользователь (отправка элементов формы, выполнение Ajax и т.д.), представлено GUID в браузере и функцией на сервере. Когда GUID представлен как часть HTTP-запроса, функция применяется (вызывается) с заданными параметрами. Поскольку GUID трудно предсказуемы и зависят от сессии, Атаки повторного воспроизведения и многие атаки с подменой параметров гораздо сложнее с Lift, чем с большинством других веб-фреймворков, включая 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-запросов в очередь и т.д.

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

Следующим основным элементом Lift является сохранение высокоуровневых абстракций как можно дольше. Со стороны генерации страницы это означает создание страницы в виде элементов 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 сопоставление шаблонов, мы сопоставляем входящий запрос, извлекаем третью часть пути и получаем User, соответствующий этому значению, и даже применяем проверку контроля доступа (имеет ли текущая сессия или запрос разрешения на доступ к данной записи User). Таким образом, к тому моменту, когда экземпляр пользователя попадает в прикладную логику, он уже проверен.

Благодаря этим двум основным компонентам Lift имеет огромное преимущество в плане безопасности. Чтобы дать вам представление о масштабах безопасности Lift, которая не мешает функциям, Расмус Лердорг, который занимался безопасностью в Yahoo!, так отозвался о FourSquare (один из сайтов-плакатов Lift):

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

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

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

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

Но Lift также предоставляет лучшую поддержку Comet среди всех существующих веб-фреймворков. Именно поэтому Novell выбрала Lift для своего продукта Pulse, и вот что Novell говорит о Lift:

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

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

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