Я знаю, что этот вопрос немного открыт, но я смотрел на Scala/Lift как альтернативу Java/Spring, и мне интересно, какие реальные преимущества у него есть Scala/Lift. С моей точки зрения и опыта Java Annotations и Spring действительно минимизируют количество кодирования, которое вы должны делать для приложения. Улучшает ли Scala/Lift?
Ответ 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.
Ответ 9
По моему скромному мнению, воображение имеет значение.
Предположим, вы хотите написать приложение. Если вы достойный разработчик, приложение уже должно строиться в вашем уме. Следующий шаг - узнать, как это работает с помощью кода. Чтобы сделать это, вам нужно передать воображаемое приложение через функцию, которая переводит его в приложение реального мира. Эта функция является языком программирования. Итак,
Real app = programming language (imagined app)
Поэтому выбор языка важен. Так и есть структура. Здесь есть масса умных людей, которые посоветуют вам, что выбрать, но в конечном счете, язык/рамки, которые лучше всего воплощают ваше воображение, должны быть вашим выбором. Итак, прототип с обоими и сделайте свой выбор.
Что касается меня, я медленно изучаю Scala и поднимаю и люблю его.
