java spring scala lift

¿Por qué debería usar Scala/Lift en lugar de Java/Spring?



(10)

Debo decir que estoy totalmente en desacuerdo con la respuesta de Dan LaRocque.

El ascensor no es monolítico. Está compuesto en elementos discretos. No ignora los elementos J / EE, es compatible con los gustos de JNDI, JTA, JPA, etc. El hecho de que no esté obligado a utilizar estos elementos de J / EE es una clara indicación del diseño modular de Lift.

  • La filosofía de vista 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 visualización basado en la ejecución del código Scala y los literales XML de Scala, y un mecanismo de visualización basado en Scalate . Si elige el mecanismo de plantillas XML, entonces elige cuánto, si es que hay alguno, marca en la lógica de su negocio. La separación de la vista de Lift es más fuerte que cualquier cosa que Spring tenga que ofrecer porque no se puede expresar ninguna lógica comercial en las plantillas XML de Lift.
  • Objeto 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 proyectos pequeños. Levante soporte JPA. Lift tiene una abstracción de registros que admite el envío de objetos dentro y fuera de las bases de datos relacionales, dentro y fuera de las tiendas NoSQL (Lift incluye soporte nativo para CouchDB y MongoDB, pero las capas de adaptador son unas pocas cientos de líneas de código, así que si quieres Cassandra o otra cosa, no es mucho trabajo conseguirlo.) Básicamente, Lift the Web Framework no depende de cómo los objetos se materializan en una sesión. Además, los ciclos de sesión y solicitud están abiertos de manera tal que insertar anotaciones de transacción en el ciclo de solicitud / respuesta es simple.
  • La filosofía de Lift es que "el equipo de servidores necesita saber un idioma, no múltiples 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 de Java en sintaxis XML para crear opciones de configuración flexibles. Significa que la sintaxis y el tipo del compilador comprueban los datos de configuración para que no obtenga ningún análisis XML extraño o datos incorrectos en el tiempo de ejecución. Esto significa que no tiene que tener IDEs que entiendan los detalles de las anotaciones que está usando en base a la biblioteca que está usando.
  • Sí, la documentación de Lift no es su punto fuerte.

Con lo dicho anteriormente, 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 que para cualquier otro marco web que yo sepa, Lift cumple con estos objetivos.

Lift at its core 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.) se representan mediante 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 suministrados. 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 alteración de parámetros son mucho más difíciles con Lift que la mayoría de los otros frameworks web, incluido Spring. También significa que los desarrolladores son más productivos porque se están enfocando en las acciones del usuario y la lógica de negocios asociada con las acciones del usuario en lugar de en la instalación de empaque y desempaquetado de una solicitud HTTP. Por ejemplo, código para aceptar o rechazar una solicitud de amistad de FourSquare:

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 primaria de la solicitud de amigo o hacer cualquier otra cosa ... simplemente defina el texto del botón ( puede ser localizado 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 retrocesos, evitar la falta de conexión al hacer cola las solicitudes de Ajax, etc.

Entonces, una gran diferencia entre Lift y Spring es que la filosofía de Lift de GUID asociada con la función tiene el doble beneficio de una seguridad mucho mejor y una productividad del desarrollador mucho mejor. La asociación GUID -> Function ha demostrado ser muy duradera ... la misma construcción funciona para las formas normales, ajax, cometas, 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 la página, 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 entre sitios, la capacidad de mover etiquetas CSS a la cabeza y los scripts al pie de la página una vez que se ha compuesto la página y la capacidad de reescribir la página según el navegador de destino. En el lado de la entrada, las URL se pueden volver a escribir para extraer los parámetros (tanto de consulta como de ruta) de forma segura, alto nivel, los datos de seguridad están disponibles para procesarlos muy pronto en el ciclo de solicitud. Por ejemplo, a continuación 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 el 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 Registro del usuario). Por lo tanto, cuando la instancia del usuario golpea la lógica de la aplicación, se verifica.

Con estas dos piezas principales, Lift tiene una gran ventaja en términos de seguridad. Para darle una idea de la magnitud de la seguridad de Lift que no se interpone en las características, Rasmus Lerdorg, que hizo la seguridad de Yahoo! tenía esto que decir acerca de FourSquare (uno de los sitios de póster-niño de Lift):

Cuatro estrellas para @foursquare: el primer sitio en un momento que he examinado bien no tenía un 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 principal objetivo era volver a escribir la versión PHP de FourSquare mientras lidiaba con el doble del tráfico semanal.

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ú. El desarrollador define las reglas de control de acceso para cada página usando el código Scala (por ejemplo, If(User.loggedIn _) o If(User.superUser _) ) y esas reglas de control de acceso se aplican antes de que comience cualquier renderización de página. Esto es muy parecido a Spring Security, excepto que está integrado desde el principio 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 al horno, resistencia a las 10 principales vulnerabilidades de seguridad de OWASP, mucho mejor soporte Ajax y una productividad de desarrollador mucho más alta que Spring.

Pero Lift también te ofrece el mejor soporte de Comet de cualquier framework web. Es por eso que Novell eligió Lift para alimentar su producto Pulse y esto es lo que Novell tiene para decir sobre Lift:

El ascensor es el tipo de marco web que le permite a usted, como desarrollador, concentrarse en el panorama general. El tipeo fuerte y expresivo y las funciones de nivel superior, como el soporte incorporado de Comet, le permiten centrarse en innovar en lugar de en la instalación de cañerías. Construir una aplicación web rica y en tiempo real como Novell Pulse requiere un marco con el poder de Lift under the covers.

Entonces, Lift no es solo otro framework de MVC de mí mismo. Es un marco que tiene algunos principios centrales de diseño que han madurado muy bien. Es un marco que brinda las dos ventajas de seguridad y productividad del desarrollador. Lift es un framework que está construido en capas y le da al desarrollador las opciones correctas basadas en sus necesidades ... opciones para la generación de vistas, opciones de persistencia, etc.

Scala y Lift brindan a los desarrolladores una experiencia mucho mejor que la mezcla de XML, anotaciones y otros modismos que conforman Spring.

Sé que esta pregunta es un poco abierta, pero he estado buscando en Scala / Lift como alternativa a Java / Spring y me pregunto cuáles son las ventajas reales que Scala / Lift tiene sobre él. Desde mi perspectiva y experiencia, Java Annotations and Spring realmente minimiza la cantidad de codificación que tienes que hacer para una aplicación. ¿Scala / Lift mejora eso?

En mi humilde opinión, la imaginación es lo que importa.

Consideremos que desea escribir una aplicación. Si eres un desarrollador decente, la aplicación ya debe ser construida en tu mente. El siguiente paso es descubrir cómo funciona a través del código. Para hacer eso, debes pasar la aplicación imaginada a través de una función que se traduzca en una aplicación del mundo real. Esa función es un lenguaje de programación. Asi que

Real app = programming language (imagined app)

Entonces la elección de idioma es importante. También lo es el marco. Hay un montón de personas inteligentes aquí que te aconsejarán sobre qué elegir, pero en última instancia, el idioma / marco que mejor traduzca tu imaginación debería ser tu elección. Prototipo con ambos y haga su elección.

En cuanto a mí, estoy aprendiendo poco a poco a Scala y Lift y me encanta.

Expandir tus conocimientos siempre es una tarea que vale la pena :) Empecé a aprender Scala, está afectando la forma en que escribo Java normal y puedo decir que ha sido muy beneficioso hasta ahora.

Intenté utilizar el elevador para un proyecto web reciente, sin ser un gran admirador de Spring MVC. No he usado las últimas versiones, pero las versiones anteriores de Spring MVC te hicieron saltar muchos aros para ejecutar una aplicación web. Casi me vendí en Lift hasta que vi que Lift puede ser muy dependiente de la sesión y requeriría ''sesiones adhesivas'' para que funcionen correctamente. Extracto de http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

Hasta que haya una tecnología de replicación de sesión estándar, aún puede agrupar su aplicación mediante "sesión adhesiva". Esto mide que todas las solicitudes relativas a una sesión HTTP deben ser procesadas por el mismo nodo de clúster

Entonces, una vez que se requiere una sesión, el usuario debería tener un pin para ese nodo. Esto crea la necesidad de equilibrar la carga inteligente y afecta la escala, lo que impidió que Lift fuera una solución en mi caso. Terminé seleccionando http://www.playframework.org/ y he estado muy contento. El juego ha sido estable y confiable hasta ahora y muy fácil de usar.

No vine a Lift y Scala desde Java, así que esto no es por experiencia personal, pero sé que muchos desarrolladores de Lift encuentran que Scala es un lenguaje mucho más conciso y eficiente que Java.

Odio lanzar tu mundo por completo. Pero puede usar Scala, Java, Lift, Spring en una sola aplicación y que no sea un problema.

Pero el principal problema es que no podemos comparar la primavera con el ascensor. Lift se utiliza básicamente como marco de interfaz de usuario y Spring se usa como marco DI.
Si está desarrollando una aplicación web que tiene una gran cantidad de back-end, asegúrese de que puede usar el ascensor.
pero si su aplicación web en desarrollo tiene algunos backend de series y definitivamente necesita pasar a la primavera.

Solo por diversión. Y por el bien de aprender nuevos enfoques de programación.

Te recomendaría que revises el marco de juego, tiene algunas ideas muy interesantes y apoya el desarrollo en Java y Scala

Supongamos que nos sentimos igualmente cómodos en Scala y Java e ignoramos las (enormes) diferencias de idioma, excepto en lo que respecta a Spring o Lift.

Spring y Lift son casi diametralmente opuestos en términos de madurez y objetivos.

  • La primavera es aproximadamente cinco años mayor que Lift
  • Lift es monolítico y se dirige únicamente a la web; Spring es modular y se dirige a aplicaciones web y "regulares"
  • Spring admite una gran cantidad de características de Java EE; Lift ignora esas cosas

En una oración, Spring es pesado y Lift es liviano. Con la determinación y los recursos suficientes, puede cambiar eso, pero necesitaría mucho de ambos.

Aquí hay diferencias concretas que se quedaron en mi mente después de trabajar con ambos marcos. Esta no es una lista exhaustiva, que no puedo compilar de ninguna manera. Justo lo que me pareció más interesante ...

  1. Ver filosofía

    El levantamiento fomenta la colocación de material de vista en métodos de fragmentos / acciones. El código de fragmento especialmente se rociará con elementos de formulario generados mediante programación, <div> s, <p> s, etc.

    Esto es poderoso y útil, especialmente porque Scala tiene un modo XML de nivel de idioma incorporado. Se puede escribir XML en línea dentro de los métodos de Scala, incluidos los enlaces de variables entre llaves. Esto puede ser encantador para servicios XML muy simples o simulaciones de servicios: puede eliminar un conjunto de acciones de respuesta HTTP, todo en un archivo espléndidamente escueto, sin plantillas ni demasiada configuración de asistente. La desventaja es la complejidad. Dependiendo de qué tan lejos llegue, hay una separación difusa de preocupaciones entre la vista y la lógica, o no hay separación.

    Por el contrario, el uso regular de Spring para webapps impone una fuerte separación entre la vista y todo lo demás. Creo que Spring admite varios motores de plantillas, pero solo he usado JSP en algo serio. Hacer un diseño de "fuzzy MVC" inspirado en Lift con JSP sería una locura. Esto es algo bueno en proyectos más grandes, donde el tiempo para leer y entender puede ser abrumador.

  2. Elección del asignador relacional de objetos

    El ORM integrado de Lift es "Mapper". Hay una nueva alternativa llamada "Record", pero creo que todavía se considera pre-alfa. El libro de LiftWeb tiene secciones sobre el uso de Mapper y JPA.

    La función CRUDify de CRUDify , tan buena como es, solo funciona con Mapper (y no con JPA).

    Por supuesto, Spring admite una variedad de tecnologías de bases de datos estándar y / o maduras . La palabra operativa allí es "apoya". Teóricamente, puede usar cualquier ORM de Java con Lift, ya que puede llamar al código arbitrario de Java desde Scala. Pero Lift solo realmente admite Mapper y (en menor medida) JPA. Además, trabajar con código Java no trivial en Scala actualmente no es tan fluido como cabría esperar; utilizando un ORM de Java, probablemente se encuentre utilizando colecciones Java y Scala en todas partes o convirtiendo todas las colecciones dentro y fuera de los componentes de Java.

  3. Configuración

    Las aplicaciones de elevación se configuran casi por completo a través de un método de clase "Boot" para toda la aplicación. En otras palabras, la configuración se realiza a través del código Scala. Esto es perfecto para proyectos con configuraciones breves, y cuando la persona que hace la configuración se siente cómoda editando Scala.

    Spring es bastante flexible en términos de configuración. Muchas de las opciones de conf pueden ser manejadas a través de la configuración XML o anotaciones.

  4. Documentación

    La documentación de Lift es joven. Los documentos de Spring son bastante maduros. No hay concurso

    Como los documentos de Spring ya están bien organizados y son fáciles de encontrar, revisaré los documentos que encontré para Lift. Básicamente hay 4 fuentes de documentación de Lift: el libro de LiftWeb , los API Doc, el grupo de Google de LiftWeb y " Getting Started ". También hay un buen conjunto de ejemplos de código, pero yo no los llamaría "documentación" per se.

    Los documentos API están incompletos. El libro de LiftWeb ha sido publicado en los árboles, pero también está disponible de forma gratuita en línea. Es realmente útil, aunque su estilo decididamente didáctico me irritó a veces. Es un poco largo en tutorial y corto en contrato. Spring tiene un manual adecuado, al cual Lift le falta.

    Pero Lift tiene un buen conjunto de ejemplos. Si te sientes cómodo leyendo el código de elevación y el código de ejemplo (y ya conoces bien a Scala), puedes resolver las cosas en poco tiempo.

Ambos marcos son convincentes. Existe una amplia gama de aplicaciones donde puedes elegir y hacerlo bien.