Devo dizer que discordo totalmente da resposta de Dan LaRocque.
A elevação não é monolítica. É composto por elementos discretos. Ele não ignora os elementos J / EE, suporta tipos JNDI, JTA, JPA, etc. O fato de você não ser forçado a usar esses elementos do J / EE é uma forte indicação do design modular do Lift.
- A filosofia da visão de Lift é "deixar o desenvolvedor decidir". O Lift oferece um mecanismo de modelo que não permite nenhum código lógico na exibição, um mecanismo de exibição baseado na execução do código Scala e literais XML do Scala e um mecanismo de exibição baseado no Scalate . Se você escolher o mecanismo de modelagem XML, poderá escolher quanto, se houver, a marcação pertence à sua lógica de negócios. A separação de visualizações do Lift é mais forte do que qualquer coisa que a Spring tenha a oferecer, porque você não pode expressar nenhuma lógica comercial nos modelos XML do Lift.
- O objeto de Lift philosophy A filosofia de persistência é "deixe o desenvolvedor decidir". O Lift possui o Mapper, que é um mapeador relacional do objeto de estilo ActiveRecord. Faz o trabalho para pequenos projetos. Levante o suporte JPA. O Lift tem uma abstração de registro que suporta a transferência de objetos para dentro e fora de bancos de dados relacionais, dentro e fora dos armazenamentos NoSQL (o Lift inclui suporte nativo para CouchDB e MongoDB, mas as camadas do adaptador são algumas centenas de linhas de código, portanto, se você quiser Cassandra ou outra coisa, não é muito trabalhoso obtê-lo.) Basicamente, o Lift the Web Framework não depende de como os objetos são materializados em uma sessão. Além disso, os ciclos de sessão e solicitação são abertos de forma que a inserção de ganchos de transação no ciclo de solicitação / resposta seja simples.
- A filosofia de Lift é "a equipe do servidor precisa conhecer um idioma, não vários idiomas". Isso significa que a configuração é feita via Scala. Isso significa que não tivemos que implementar 40% das construções da linguagem Java na sintaxe XML para criar opções de configuração flexíveis. Isso significa que a sintaxe do compilador e verifica os dados de configuração para que você não obtenha nenhuma análise XML estranha ou dados incorretos no tempo de execução. Significa que você não precisa ter IDEs que entendam os detalhes das anotações que você está usando, com base na biblioteca que está usando.
- Sim, a documentação do Lift não é seu ponto forte.
Com o exposto, deixe-me falar um pouco sobre a filosofia de design do Lift.
Escrevi o Manifesto do Web Framework antes de começar a escrever o Lift. Em grande parte e em maior grau do que qualquer outra estrutura da Web que eu conheça, o Lift atende a esses objetivos.
O Lift em sua essência procura abstrair o ciclo de solicitação / resposta HTTP em vez de colocar wrappers de objeto em torno da Solicitação HTTP. No nível prático, isso significa que quase todas as ações que um usuário pode executar (enviar elementos de formulário, executar Ajax etc.) são representadas por um GUID no navegador e uma função no servidor. Quando o GUID é apresentado como parte de uma solicitação HTTP, a função é aplicada (chamada) com os parâmetros fornecidos. Como os GUIDs são difíceis de prever e específicos da sessão, os ataques de repetição e muitos ataques de violação de parâmetros são muito mais difíceis com o Lift do que a maioria das outras estruturas da Web, incluindo o Spring. Isso também significa que os desenvolvedores são mais produtivos porque se concentram nas ações do usuário e na lógica de negócios associada às ações do usuário, em vez do encanamento de empacotar e descompactar uma solicitação HTTP.
ajaxButton("Accept", () => {request.accept.save;
SetHtml("acceptrejectspan", <span/>}) ++
ajaxButton("Reject", () => {request.reject.save;
SetHtml("acceptrejectspan", <span/>})
É simples assim. Como o friendRequest está no escopo quando a função é criada, a função fecha sobre o escopo ... não há necessidade de expor a chave primária da solicitação de amizade ou fazer qualquer outra coisa ... basta definir o texto do botão (ele pode ser localizado ou extraído de um modelo XHTML ou extraído de um modelo localizado) e a função a ser executada quando o botão é pressionado. O Lift cuida da atribuição do GUID, da configuração da chamada Ajax (via jQuery ou YUI, e sim, você pode adicionar sua própria biblioteca JavaScript favorita), realizando tentativas automáticas com afastamentos, evitando a inanição da conexão na fila de solicitações do Ajax, etc.
Portanto, uma grande diferença entre o Lift e o Spring é que a filosofia do GUID do Lift associada à função tem o duplo benefício de uma segurança muito melhor e uma produtividade do desenvolvedor muito melhor. A associação GUID -> Function provou ser muito durável ... a mesma construção funciona para formas normais, ajax, cometa, assistentes de várias páginas, etc.
A próxima parte principal do Lift é manter as abstrações de alto nível por mais tempo possível. No lado da geração da página, isso significa criar a página como elementos XHTML e mantê-la como XHTML até pouco antes de transmitir a resposta. Os benefícios são a resistência a erros de script entre sites, a capacidade de mover tags CSS para a cabeça e scripts para a parte inferior da página após a composição da página e a capacidade de reescrever a página com base no navegador de destino. No lado da entrada, os URLs podem ser reescritos para extrair parâmetros (tanto os parâmetros de consulta quanto o caminho) de uma maneira segura e de alto nível, dados verificados de segurança estão disponíveis para processamento muito cedo no ciclo de solicitação. Por exemplo, veja como definir a manutenção de uma solicitação REST:
serve {
case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
}
Usando a correspondência de padrões incorporada do Scala, correspondemos a uma solicitação recebida, extraímos a terceira parte do caminho e obtemos o Usuário que corresponde a esse valor e até aplicamos verificações de controle de acesso (a sessão ou solicitação atual tem permissões para acessar a determinada Registro do usuário). Portanto, quando a instância do usuário atinge a lógica do aplicativo, ela é examinada.
Com essas duas peças principais, o Lift tem uma enorme vantagem em termos de segurança. Para ter uma idéia da magnitude da segurança do Lift que não atrapalha os recursos, Rasmus Lerdorg, que fez a segurança do Yahoo! tinha a dizer sobre o FourSquare (um dos sites filhos do pôster do Lift):
Quatro estrelas no @foursquare - 1º site há algum tempo, observei que não havia um único problema de segurança (que eu poderia encontrar) - http://twitter.com/rasmus/status/5929904263
Na época, o FourSquare tinha um engenheiro trabalhando no código (não que @harryh não fosse um super-gênio) e seu foco principal era reescrever a versão PHP do FourSquare enquanto lidava com a duplicação de tráfego semanal.
A última parte do foco de segurança do Lift é o SiteMap. É um controle de acesso unificado, navegação no site e sistema de menus. O desenvolvedor define as regras de controle de acesso para cada página usando o código Scala (por exemplo, If(User.loggedIn _)ou If(User.superUser _)) e essas regras de controle de acesso são aplicadas antes do início de qualquer renderização de página. Isso é muito parecido com o Spring Security, exceto pelo fato de ele ser incorporado desde o início do projeto e as regras de controle de acesso serem unificadas com o restante do aplicativo, para que você não precise ter processo para atualizar as regras de segurança em XML quando os URLs ou os métodos que calculam a alteração do controle de acesso.
Para resumir até agora, a filosofia de design do Lift oferece os benefícios de controle de acesso, resistência às 10 principais vulnerabilidades de segurança da OWASP, suporte Ajax muito melhor e produtividade do desenvolvedor muito maior do que a Spring.
Mas o Lift também oferece o melhor suporte ao Cometa de qualquer estrutura da Web. É por isso que a Novell escolheu o Lift para alimentar seu produto Pulse e aqui está o que a Novell tem a dizer sobre o Lift:
Lift é o tipo de estrutura da web que permite que você, como desenvolvedor, se concentre no cenário geral. Digitação forte e expressiva e recursos de nível superior, como o suporte interno do Comet, permitem que você se concentre na inovação em vez do encanamento. A criação de um aplicativo Web rico e em tempo real como o Novell Pulse requer uma estrutura com o poder do Lift sob as cobertas.
Portanto, o Lift não é apenas mais uma estrutura MVC "eu-também". É uma estrutura que possui alguns princípios básicos de design que amadureceram muito bem. É uma estrutura que oferece as vantagens duplas de segurança e produtividade do desenvolvedor. O Lift é uma estrutura construída em camadas e oferece ao desenvolvedor as escolhas certas com base em suas necessidades ... opções para geração de visualizações, opções para persistência etc.
O Scala e o Lift oferecem aos desenvolvedores uma experiência muito melhor do que a mistura de XML, anotações e outros idiomas que compõem o Spring.