Зачем мне использовать Scala / Lift поверх Java / Spring? [закрыто]

Я знаю, что этот вопрос немного открыт, но я смотрю на Scala / Lift как на альтернативу Java / Spring, и мне интересно, каковы реальные преимущества Scala / Lift по сравнению с ним. С моей точки зрения и опыта, Java Annotations and Spring действительно сводит к минимуму объем кода, который вы должны сделать для приложения. Улучшает ли это Scala / Lift?

Давайте предположим, что мы одинаково удобны в Scala и Java и игнорируем (огромные) языковые различия, за исключением того, что они относятся к Spring или Lift.

Spring и Lift почти диаметрально противоположны с точки зрения зрелости и целей.

• Весна на пять лет старше Лифта
• Лифт монолитен и нацелен только на сеть; Spring модульный и предназначен как для веб, так и для «обычных» приложений
• Spring поддерживает множество функций Java EE; Лифт игнорирует этот материал

В предложении Spring тяжелый, а Lift легкий. С достаточной решимостью и ресурсами вы можете повернуть это с ног на голову, но вам понадобится много и того, и другого.

Вот конкретные различия, которые застряли у меня в голове после работы с обеими платформами. Это не исчерпывающий список, который я никак не могу составить. Именно то, что мне показалось наиболее интересным ...

1. Посмотреть философию

   Лифт поощряет размещение некоторого материала представления во фрагментах / методах действия. В частности, фрагмент кода будет содержать программно сгенерированные элементы формы, <div>s, <p>s и т. Д.

   Это мощный и полезный инструмент, тем более что Scala имеет встроенный режим XML на уровне языка. Можно написать XML встроенный в методы Scala, включая привязки переменных в фигурных скобках. Это может быть восхитительно для очень простых XML-сервисов или макетов сервисов - вы можете объединить набор ответных HTTP-действий в одном великолепном кратком файле без шаблонов или большого количества сопутствующих настроек. Недостатком является сложность. В зависимости от того, как далеко вы продвинулись, существует либо нечеткое разделение интересов между взглядом и логикой, либо отсутствие разделения.

   Напротив, регулярное использование Spring для веб-приложений обеспечивает сильное разделение между представлением и всем остальным. Я думаю, что Spring поддерживает несколько шаблонизаторов, но я использовал JSP только в чем-то серьезном. Создание «нечеткого MVC» в стиле Lift с JSP было бы безумием. Это хорошо для больших проектов, где время, чтобы просто прочитать и понять, может быть огромным.

2. Объектно-реляционный выбор картографов

   Встроенный ORM лифта - "Mapper". Существует грядущая альтернатива под названием «Запись», но я думаю, что она все еще считается пре-альфа. В книге LiftWeb есть разделы, посвященные использованию Mapper и JPA.

   Крутая функция Lift CRUDify работает только с Mapper (а не с JPA).

   Конечно, Spring поддерживает множество стандартных и / или зрелых технологий баз данных . Оперативное слово там "поддерживает". Теоретически вы можете использовать любой Java ORM с Lift, поскольку вы можете вызывать произвольный код Java из Scala. Но Lift действительно поддерживает только Mapper и (в гораздо меньшей степени) JPA. Кроме того, работа с нетривиальным Java-кодом в Scala в настоящее время не так проста, как хотелось бы; Используя Java ORM, вы, вероятно, обнаружите, что будете использовать повсеместно как коллекции Java, так и Scala, или конвертировать все коллекции в компоненты Java и из них.

3. конфигурация

   Приложения Lift настраиваются в основном полностью с помощью метода, который является классом Boot для всего приложения. Другими словами, конфигурация выполняется через код Scala. Это идеально подходит для проектов с краткими настройками, и когда человек, выполняющий настройку, может свободно редактировать Scala.

   Spring довольно гибок в плане конфигурации. Множество опций conf может быть настроено с помощью конфигурации XML или аннотаций.

4. Документация

   Документация Лифта молода. Документы Spring довольно зрелые. Там нет конкурса.

   Поскольку документы Spring уже хорошо организованы и их легко найти, я рассмотрю документы, которые я нашел для Lift. В основном существует 4 источника документации по Lift: LiftWeb Book , API Docs , группа Google LiftWeb и « Начало работы ». Есть также хороший набор примеров кода, но я бы не назвал их «документацией» как таковой.

   Документы по API неполные. Книга LiftWeb была опубликована на деревьях, но она также свободно доступна онлайн. Это действительно полезно, хотя его решительно дидактический стиль раздражал меня время от времени. Это немного длинный учебник и короткий контракт. У Spring есть надлежащее руководство, которого нет у Lift.

   Но у Лифта есть хороший набор примеров. Если вам удобно читать код Lift и пример кода (и вы уже хорошо знаете Scala), вы можете разобраться в этом довольно быстро.

Обе основы являются убедительными. Существует широкий спектр приложений, в которых вы можете выбрать любой из них и добиться успеха.

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

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

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

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

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

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

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, комет, многостраничных мастеров и т. Д.

Следующей основной частью 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 попадает в логику приложения, он проверяется.

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

Четыре звезды на @foursquare - 1-й сайт за то время, что я внимательно посмотрел, у которого не было ни одной проблемы безопасности (которую я мог бы найти) - 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.

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

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

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

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

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

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

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

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

По моему скромному мнению, воображение имеет значение.

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

Real app = programming language (imagined app)

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

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

Но главная проблема в том, что мы не можем сравнить весну с подъемом. Lift в основном используется как UI Framework, а Spring - как DI Framework.
Если вы разрабатываете веб-приложение, в котором есть так много бэкэнда, вы можете использовать lift.
но если вы разрабатываете веб-приложение, у которого есть какой-то ряд бэкэнда, и вы определенно должны перейти к весне.