Почему я должен использовать Scala/Лифт над Java/Spring?

Ответ 1

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

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

• Spring примерно на пять лет старше лифта.
• Подъемник монолитный и предназначен только для сети; Spring является модульным и ориентирован как на веб, так и на "обычные" приложения.
• Spring поддерживает множество возможностей Java EE; Лифт игнорирует этот материал.

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

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

• Просмотр философии

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

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

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

• Выбор объектно-реляционного сопоставления

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

  Поднимите функцию CRUDify, круто, как есть, работает только с Mapper (а не JPA).

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

• Конфигурация

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

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

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

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

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

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

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

Оба фреймворка убедительны. Там широкий спектр приложений, где вы можете выбирать и делать хорошо.

Ответ 2

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

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

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

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

Я написал манифест веб-макета, прежде чем начал писать лифт. В значительной степени, и в большей степени, чем это верно для любых других веб-фреймворков, о которых я знаю, 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 или вытащить из локализованного шаблона) и функцию, выполняемую при нажатии кнопки. Лифт берет на себя обязательство назначать GUID, настраивая вызов Ajax (через jQuery или YUI, и да, вы можете добавить свою собственную любимую библиотеку JavaScript), выполнять автоматические повторные попытки с резервными копиями, избегая голодания в голосе путем очередности запросов Ajax и т.д.

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Real app = programming language (imagined app)

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

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

Ответ 10

Но главная проблема заключается в том, что мы не можем сравнивать spring с лифтом. Лифтинг в основном используется в качестве инфраструктуры пользовательского интерфейса, а spring используется в качестве рамки DI.
Если вы разрабатываете веб-приложение, у которого есть такая поддержка, вы можете воспользоваться лифтом.
но если ваше развивающееся веб-приложение, у которого есть ряд бэкэндов серии, и вам определенно нужно перейти spring.