Palestra VRaptor 3

151 visualizações

Publicada em

Slides utilizados para uma palestra sobre VRaptor 3, um framework brasileiro criado pela Caleum.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
151
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • O VRaptor 3 foca em simplicidade e, portanto, todas as funcionalidades que você verá têm como meta resolver o problema do programador da maneira menos intrusiva possível em seu código.
    Sempre procura encapsular HttpServletRequest, Response, Session e toda a API do javax.servlet.
    Deixar que o framework cuide da parte web e deixe você focar na linguagem de programação.
    Os criadores tentaram pegar o melhor de vários frameworks para fazer o próprio.
  • O VRaptor trabalha muito com convenções em vez de configurações, portanto, para que nosso sistema funcione, devemos organizar nossos arquivos obedecendo a seguinte convenção: ao criar um controller, suas views devem ficar dentro de uma pasta com o nome idêntico ao do mesmo sendo que com a inicial minúscula.
    Cada .jsp dentro desta pasta deverá possuir o mesmo nome que os métodos correspondentes em seus respectivos controllers.
    Cada pasta deve ficar dentro de uma pasta chamada “jsp”
  • Repare que a classe não herda de nenhuma outra classe nem implementa nenhuma interface. É um exemplo claro de um POJO.
    Anotando o controller com @Resource, seus métodos públicos ficarão disponíveis para receber requisições web.
  • Ao terminar a execução do método, por convenção, o VRaptor fará o dispatch da requisição para o JSP /WEB-INF/jsp/olaMundo/ola.jsp
  • No VRaptor, o retorno do método é exportado para a JSP por meio de atributos da requisição.
  • No caso do método lista, vai existir um atributo chamado stringList contendo a lista retornada
    Se for uma classe qualquer vai ser o nome da classe com a primeira letra minúscula
  • O VRaptor está fortemente baseado no conceito de injeção de dependências do Spring, uma vez que chega até mesmo a utilizar dessa ideia para juntar seus componentes internos.
    Dependência é tudo que um objeto precisa para que seus métodos executem com sucesso.
    O conceito básico de DI (Dependency Injection) é que tudo que um objeto depende deve ser entregue a ele, em vez de ele ter que ir atrás de cada uma de suas dependências.
    Pra isso, anotamos com @Component todas as classes que são dependência de alguma outra. Então o VRaptor se encarregará de instanciar as classes e injetar as dependências quando ele ver que determinada classe pede um certo objeto em seu construtor.
  • Nesse caso, Result é uma classe interna do próprio VRaptor que já está configurada como dependência.
    Já ProdutoDao foi anotada como dependência por nós.
  • Geralmente em outros framekworks, quando termina uma ação a gente manda para a aplicação ir para uma determinada URI. Mas se essa URI mudar um dia quebra toda tua aplicação. Em vez de, por exemplo, ir num arquivo de configuração (que é uma terceirização), a gente faz isso a nível de código no próprio controller. Isso favorece o refactor, pois por exemplo, se eu refatorar meu método, eu reflito isso nos meus redirecionamentos.

    O redirect acontece no lado do cliente, através de códigos HTTP que farão o browser acessar uma nova URL;
    Já o forward acontece no lado do servidor, totalmente transparente para o cliente/browser.

    Um bom exemplo de uso do redirect é no chamado 'redirect-after-post'. Por exemplo: quando você adiciona um cliente e que, após o formulário submetido, o cliente seja retornado para a página de listagem de clientes. Fazendo isso com redirect, impedimos que o usuário atualize a página (F5) e reenvie toda a requisição, acarretando em dados duplicados.

    No caso do forward, um exemplo de uso é quando você possui uma validação e essa validação falhou, geralmente você quer que o usuário continue na mesma tela do formulário com os dados da requisição preenchidos, mas internamente você vai fazer o forward para outra lógica de negócios (a que prepara os dados necessários para o formulário).
  • @Request: o componente será criado sempre a cada requisição
    @Session: o compoenente será criado um vez por sessão
    @Application: o componente será criado uma única vez em todo o tempo de vida da aplicação
    @Prototype: o componente será criado sempre que for solicitado
  • VRaptor permite anotações bem uteis do Java EE 5, as quais devem ser utilizadas em métodos

    Dessa forma podemos usar o @PostConstruct para criação da fábrica de sessões
    E usar o @PreDestroy pra fechar a nossa fábrica
  • Maneira clássica: você faz os if’s e coloca as mensagens manualmente;
    Maneira fluente: você diz o que quer que seja verdade, e caso não seja, adiciona uma mensagem internacionalizada (tem colocar as chaves no seu arquivo message.properties);
    Em ambas as maneiras é preciso indicar para onde voltar quando ocorrer algum erro. No nosso caso, queremos voltar para o formulário.
  • No estilo fluente, estabelecemos a regra. Se não for obedecida, estouramos o erro
    A ideia é que o código para fazer a validação seja algo muito parecido com a linguagem natural
  • No estilo fluente, a ideia é que o código para fazer a validação seja algo muito parecido com a linguagem natural
  • REST é um conjunto de restrições que define um padrão arquitetural com características específicas.
    Permite o endereçamento dos recursos de forma padronizada.
  • Requisição HTTP tem três tipos de componentes importantes.
    Uma aplicação RESTful costuma reforçar mais ss sbustantivos do que os verbos.
    A vantagem de seguir isso é que conseguimos aproveitar toda a estrutura que o protocolo HTTP proporciona
  • Quando fazemos requisições web nós precisamos falar o caminho da mesma, a URI, ou seja, o identificador de um recurso.
    Para representar a adição de um produto por exemplo, podemos usar a URI /produto aliado ao método Post do HTTP, o qual representa adição de dados.
  • Uma boa e importante prática do REST é que você tenha uma conjunto pequeno e fixo de operações bem definidas, gerando assim uma interface uniforme.
    É interessante que duas aplicações diferentes conversem entre si sem implementar várias operações diferentes.
    Perceba que adicionar um produto é basicamente a mesma ação que adicionar um usuário. Padronize isto!
  • Put != Post, pois no Post a URI indica o local onde será tratada a informação, já no Put indica o local será armazenada a informação.

    Head: recupera o Header
    Options: recupera quais métodos são possíveis
    Trace: informações de debug.

    Quando fazemos uma aplicação, não trafegamos um recurso pela rede, mas sim a representação dele.
  • Cada verbo HTTP tem uma semântica diferente, se uma operação não segue a semântica dos verbos, não se deve aceitar o mesmo.
    Exemplo: o método “listaTudo()” é uma operação idempotente, ou seja, pode ser chamada quantas vezes quiser que não vai haver nenhum efeito colateral, e se o banco não mudou, vai ter sempre o mesmo resultado. Logo, faz sentido que o verbo HTTP para acessar esse método seja o Get.

    A partir do momento que colocamos uma anotação de verbo HTTP no nosso método, ele não pode mais ser acessado pelos outros verbos.
    Se tentarmos fazer uma requisição Post pra “/produto”, a requisição vai retornar um status 405 (Método não suportado), que quer dizer que existe um recurso nessa URI, mas que não suporta o verbo HTTP Post.
  • Mas podemos colocar mais um método que responda à mesma URI, desde que os verbos HTTP sejam diferentes.
    Nesse nosso caso, fazemos com que o método “add()” seja atendido pela mesma URI “/produto” do método “listaTudo()” porém, usando o verbo HTTP Post. E como esta operação não é idempotente, se eu repetir duas vezes uma requisição, vou estar adicionando dois produtos, não sabemos qual vai ser a URI dele, por isso cabe perfeitamente usar o verbo Post.
  • No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia. Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
  • No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia.
    Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
  • No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia. Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
  • ALTA PRODUTIVIDADEa
    Usar o VRaptor 3 é simples e intuitivo. Você atingirá níveis altíssimos de produtividade com Java para Web.

    CURVA DE APRENDIZADO
    Em pouco tempo você conseguirá aprender tudo o que é necessário para desenvolver suas aplicações com o VRaptor.

    TESTABILIDADE
    Escreva código modularizado e desacoplado do VRaptor. Sua aplicação fica altamente testável e de fácil manutenção.

    ECONOMIA
    Economize muitas horas de trabalho com a alta produtividade do VRaptor, a facilidade em treinar a sua equipe e a qualidade final do seu projeto.

    FLEXIBILIDADE
    Integre o seu projeto com qualquer framework de sua preferência. Você não estará preso a nenhuma tecnologia específica.

    MELHORES PRÁTICAS DE DESENVOLVIMENTO
    Utilizando os conceitos de Injeção de Dependência, Inversão de Controle e POJOs, seu código fica simples e testável.
  • Palestra VRaptor 3

    1. 1.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    2. 2.  Framework MVC brasileiro  Desenvolvido pela Caelum  Inspirado no Ruby on Rails  Focado no desenvolvimento ágil  Diminui drasticamente tempo de trabalho  Convenção sobre configuração  Roda sobre o Spring
    3. 3.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    4. 4.  Convenção de acesso à view: WEB-INF/jsp/{nomeDoResource}/{nomeDoMétodo}.jsp  No nosso caso: WEB-INF/jsp/olaMundo/ola.jsp  Como acessaremos a view: localhost:8080/PalestraVRaptor/olaMundo/ola
    5. 5.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    6. 6.  Quais são minhas dependências?  Quem instanciará as classes?  Como o Vraptor sabe disso?
    7. 7.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    8. 8.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    9. 9.  @RequestScoped (padrão)  @SessionScoped  @ApplicationScoped  @PrototypeScoped
    10. 10.  @PostConstruct: assim que o escopo for iniciado  @PreDestroy: assim que o escopo for finalizado
    11. 11.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    12. 12.  Componente Validator do VRaptor  Maneira clássica  Maneira fluente  Integração com o Hibernate Validator  Especificar para qual lógica encaminhar
    13. 13.  Validador do VRaptor integrado com o Hibernate Validator
    14. 14.  O que é o VRaptor?  Primeiro contato  Injeção de dependências  Enviando dados via form  Escopos definidos  Validação  REST
    15. 15.  Representation State Tranfer  Padrão arquitetural  Endereçamento de forma padronizada (nice urls)  Maior visibilidade para componentes intermediários  Diminui acoplamento entre cliente e servidor
    16. 16. Substantivos Verbos Content types
    17. 17.  URI (Unified Resource Identifier)  Nome dos recursos  Recursos != Ações  Má prática: /produto/adiciona
    18. 18.  Conjunto pequeno e fixo de operações  Interface uniforme  Operações HTTP: › Get, Post, Put, › Delete, Head, Options, Trace
    19. 19.  Get: recuperar dados de um recurso  Post: adiciona dados de um recurso  Put: adiciona ou modifica dados  Delete: deleta o recurso representado na URI  Head, Options, Trace: recuperam metadados da URI
    20. 20.  Alta produtividade  Curva de aprendizado  Testabilidade  Economia  Flexibilidade  Melhores práticas de desenvolvimento

    ×