Tengo que decir que estoy totalmente en desacuerdo con la respuesta de Dan LaRocque.
El ascensor no es monolítico. Se compone de elementos discretos. No ignora los elementos J / EE, admite JNDI, JTA, JPA, etc. El hecho de que no esté obligado a usar estos elementos de J / EE es una fuerte indicación del diseño modular de Lift.
- La filosofía de visión de Lift es "dejar que el desarrollador decida". Lift ofrece un mecanismo de plantillas que no permite ningún código lógico en la vista, un mecanismo de vista basado en la ejecución del código Scala y los literales XML de Scala, y un mecanismo de vista basado en Scalate . Si elige el mecanismo de creación de plantillas XML, entonces elige la cantidad de marcado, si corresponde, en su lógica comercial. La separación de vistas de Lift es más fuerte que cualquier cosa que Spring tenga para ofrecer porque no puede expresar ninguna lógica de negocios en las plantillas XML de Lift.
- El objetivo de Lift ↔ La filosofía de persistencia es "dejar que el desarrollador decida". Lift tiene Mapper, que es un mapeador relacional de objetos de estilo ActiveRecord. Hace el trabajo para pequeños proyectos. Soporte elevador JPA. Lift tiene una abstracción de registro que admite el traslado de objetos dentro y fuera de bases de datos relacionales, dentro y fuera de almacenes NoSQL (Lift incluye soporte nativo para CouchDB y MongoDB, pero las capas de adaptador son unos cientos de líneas de código, así que si quieres Cassandra o algo más, no es mucho trabajo conseguirlo.) Básicamente, Lift the Web Framework no depende de cómo se materializan los objetos en una sesión. Además, los ciclos de sesión y solicitud están abiertos de tal manera que insertar ganchos de transacción en el ciclo de solicitud / respuesta es simple.
- La filosofía de Lift es "el equipo del servidor necesita saber un idioma, no varios idiomas". Esto significa que la configuración se realiza a través de Scala. Esto significa que no tuvimos que implementar el 40% de las construcciones de lenguaje Java en sintaxis XML para crear opciones de configuración flexibles. Significa que la sintaxis y el tipo del compilador verifican los datos de configuración para que no obtenga ningún análisis XML extraño o datos incorrectos en tiempo de ejecución. Esto significa que no tiene que tener IDE que comprendan los detalles de las anotaciones que está utilizando en función de la biblioteca que está utilizando.
- Sí, la documentación de Lift no es su punto fuerte.
Dicho lo anterior, permítanme hablar un poco sobre la filosofía de diseño de Lift.
Escribí Web Framework Manifesto antes de comenzar a escribir Lift. En gran medida, y en mayor medida de lo que es cierto para cualquier otro marco web que conozco, Lift cumple con estos objetivos.
Levantar en su núcleo busca abstraer el ciclo de solicitud / respuesta HTTP en lugar de colocar envoltorios de objetos alrededor de la solicitud HTTP. En el nivel práctico, esto significa que la mayoría de las acciones que puede realizar un usuario (enviar elementos de formulario, hacer Ajax, etc.) están representadas por un GUID en el navegador y una función en el servidor. Cuando el GUID se presenta como parte de una solicitud HTTP, la función se aplica (se llama) con los parámetros proporcionados. Debido a que los GUID son difíciles de predecir y específicos de la sesión, los ataques de repetición y muchos ataques de manipulación de parámetros son mucho más difíciles con Lift que la mayoría de los otros marcos web, incluido Spring. También significa que los desarrolladores son más productivos porque se están centrando en las acciones del usuario y la lógica de negocios asociada con las acciones del usuario en lugar de la plomería de empaquetar y desempaquetar una solicitud HTTP.
ajaxButton("Accept", () => {request.accept.save;
SetHtml("acceptrejectspan", <span/>}) ++
ajaxButton("Reject", () => {request.reject.save;
SetHtml("acceptrejectspan", <span/>})
Es así de simple. Debido a que friendRequest está en el alcance cuando se crea la función, la función se cierra sobre el alcance ... no hay necesidad de exponer la clave principal de la solicitud de amistad o hacer otra cosa ... solo defina el texto del botón (se puede localizarse o puede extraerse de una plantilla XHTML o puede extraerse de una plantilla localizada) y la función para ejecutar cuando se presiona el botón. Lift se encarga de asignar el GUID, configurar la llamada Ajax (a través de jQuery o YUI, y sí, puede agregar su propia biblioteca de JavaScript favorita), hacer reintentos automáticos con retrasos, evitar el hambre de conexión haciendo cola las solicitudes de Ajax, etc.
Entonces, una gran diferencia entre Lift y Spring es que la filosofía de GUID de Lift asociada con la función tiene el doble beneficio de una seguridad mucho mejor y una productividad del desarrollador mucho mejor. El GUID -> La asociación de funciones ha demostrado ser muy duradera ... la misma construcción funciona para formas normales, ajax, cometa, asistentes de varias páginas, etc.
La siguiente pieza central de Lift es mantener las abstracciones de alto nivel durante el mayor tiempo posible. En el lado de la generación de páginas, eso significa construir la página como elementos XHTML y mantener la página como XHTML hasta justo antes de transmitir la respuesta. Los beneficios son la resistencia a los errores de secuencias de comandos en sitios cruzados, la capacidad de mover etiquetas CSS al encabezado y las secuencias de comandos al final de la página una vez que la página ha sido compuesta, y la capacidad de reescribir la página según el navegador de destino. En el lado de entrada, las URL se pueden volver a escribir para extraer parámetros (parámetros de consulta y ruta) de forma segura, los datos de alto nivel y de seguridad están disponibles para su procesamiento muy temprano en el ciclo de solicitud. Por ejemplo, aquí se explica cómo definir el servicio de una solicitud REST:
serve {
case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
}
Usando la coincidencia de patrones incorporada de Scala, hacemos coincidir una solicitud entrante, extraemos la tercera parte de la ruta y obtenemos al Usuario que corresponde a ese valor, e incluso aplicamos controles de control de acceso (¿la sesión o solicitud actual tiene permisos para acceder a la determinada? Registro de usuario). Por lo tanto, cuando la instancia de usuario alcanza la lógica de la aplicación, se verifica.
Con estas dos piezas centrales, Lift tiene una tremenda ventaja en términos de seguridad. Para darle una idea de la magnitud de la seguridad de Lift que no se interpone en el camino de las características, Rasmus Lerdorg, que hizo seguridad para Yahoo! tenía esto que decir sobre FourSquare (uno de los sitios secundarios de póster de Lift):
Cuatro estrellas para @foursquare - 1er sitio en un tiempo he echado un buen vistazo a eso no tenía un solo problema de seguridad (que pude encontrar) - http://twitter.com/rasmus/status/5929904263
En ese momento, FourSquare tenía un ingeniero trabajando en el código (no es que @harryh no sea un súper genio) y su enfoque principal era reescribir la versión PHP de FourSquare mientras se enfrentaba a la duplicación semanal del tráfico.
La última parte del enfoque de seguridad de Lift es SiteMap. Es un control de acceso unificado, navegación del sitio y sistema de menús. El desarrollador define las reglas de control de acceso para cada página usando el código Scala (p. Ej. If(User.loggedIn _)O If(User.superUser _)) y esas reglas de control de acceso se aplican antes de que comience cualquier representación de página. Esto es muy parecido a Spring Security, excepto que está integrado desde el comienzo del proyecto y las reglas de control de acceso están unificadas con el resto de la aplicación, por lo que no es necesario tener un proceso para actualizar las reglas de seguridad en XML cuando las URL cambio o los métodos que calculan el cambio de control de acceso.
Para resumir hasta ahora, la filosofía de diseño de Lift le brinda los beneficios del control de acceso integrado, la resistencia a las 10 vulnerabilidades de seguridad de OWASP, un mejor soporte de Ajax y una productividad de desarrollador mucho mayor que Spring.
Pero Lift también le brinda el mejor soporte de Comet de cualquier marco web existente. Es por eso que Novell eligió Lift para impulsar su producto Pulse y esto es lo que Novell tiene que decir sobre Lift:
Lift es el tipo de marco web que le permite a usted como desarrollador concentrarse en el panorama general. La escritura fuerte y expresiva y las características de nivel superior, como el soporte Comet incorporado, le permiten concentrarse en innovar en lugar de en la plomería. La creación de una aplicación web rica y en tiempo real como Novell Pulse requiere un marco con el poder de Lift bajo las cubiertas.
Entonces, Lift no es solo otro marco MVC de yo también. Es un marco que tiene algunos principios básicos de diseño que han madurado muy bien. Es un marco que ofrece las ventajas dobles de seguridad y productividad del desarrollador. Lift es un marco que está construido en capas y le da al desarrollador las opciones correctas en función de sus necesidades ... opciones para la generación de vistas, opciones para la persistencia, etc.
Scala y Lift ofrecen a los desarrolladores una experiencia mucho mejor que la mezcla de XML, anotaciones y otros modismos que componen Spring.