Criando a camada WEB com Spring-WEBMVC – @Annotation
Spring WebMVC é uma ferramenta poderosa para criação de aplicação com uma camada web muito utilizada no mercado.
Algumas de suas características incluem uma separação clara entre camada de apresentação, negócios e modelo, e também uma distinção clara de papéis de controllers, validators, commands, forms, models, views etc. Também é um framework altamente customisável e adaptável, disponibilizando ferramentas para controle de todo o fluxo entre as páginas e se adaptando bem a maioria dos modelos de negócio. Outra característica que é quase obrigatória em todos os módulos do Spring, é o padrão Spring de se organizar e configurar as classes de negócio como beans gerenciados pelo container.
Além das características básicas, ainda estão disponíveis bibliotecas de JSP muito úteis no dia-a-dia de desenvolvimento que facilitam a contrução de interfaces. E ainda existe a possibilidade de configurar os escopos dos beans da aplicação de acordo com o lifecycle do HTTP request que está sendo feito para a aplicação.
Neste post veremos o básico de spring-webmvc e sua configuração feita por anotações, aprendendo os conceitos base do módulo e entendendo melhor como configurar e organizar seus beans de acordo com suas necessidades. Por fim veremos um screencast com um exemplo de aplicação web feita do zero e seguindo todo o caminho desde o modelo, passando pelo controller e terminando na view.
Entendendo o DispatcherServlet
O DispatcherServlet é de fato um servlet Java que é o ponto de entrada para as aplicações Web.
É encarregado de encaminhar as chamadas feitas a aplicação para seu respectivo controller, e uma vez que a resposta do controller foi recebida, encaminhas a resposta para a view correta. Mas como DispatcherServlet faz parte do Spring, para ele e seus beans, nesse caso controllers e suas dependências, estão disponíveis todas as outras features que o container disponibiliza, como gerenciamento de beans e injeção de dependências.
O DispatcherServlet seguem um Design Pattern conhecido como Front Controller. No site do spring está disponível o seguinte diagrama exemplificando o pattern:
No diagrama fica claro o papel do DispatcherServlet.
Uma chamada que acabou de chegar na aplicação, passa pelo DispatcherServlet, que por sua vez escolhe o controller correto para tratar a chamada e delega a mesma. Feito isso o controller devolve o resultado da operação para o DispatcherServlet que dessa vez se encarrega de encontrar a view correta para tratar a resposta. Após a view ter renderizado a página de resposta, o DispatcherServlet devolve para o dono da requisição a resposta.
Configurando o DispatcherServlet
Agora que entendemos que o DispatcherServlet é peça fundamental para nossa aplicação, precisamo configurá-lo. Para isso basta adicioná-lo ao seu arquivo web.xml da seguinte forma:
[cc_xml]
[/cc_xml]
O que fizemos foi dizer ao server, que ele deve instanciar um novo servlet, que nesse caso é o DispatcherServlet, assim que a aplicação subir no servidor. Também estamos dizendo que todas as chamadas para a aplicação, que forem feitas em / devem ser delegadas para o nosso servlet com o nome servletName. Nesse campo você pode escolher o nome que mais fizer sentido para sua aplicação, e perceba que você pode criar mais de um servlet para tratar suas chamadas.
Agora vamos à integração com o IoC do Spring.
Como eu havia dito, esse é um dos benefícios do Spring-WebMVC, e portanto vamos ver como usá-lo corretamente para tirar maior proveito do mesmo.
Todo DispatcherServlet está associado a um contexto de beans do Spring. Tal associação é feita através do nome do servlet e um arquivo de beans padrão do spring. No momento em que o DispatcherServlet for criado, o classpath será percorrido em procura de uma arquivo que, neste caso, deve se chamar /WEB-INF/servletName-servlet.xml. Neste arquivo devem estar definidos os beans específicos para que os seus controllers referentes a este servlet funcionem corretamente. Note que se estiver definido mais de um DispatcherServlet, será necessário definir um arquivo com tais beans para cada um deles.
Controllers
Controllers são parte fundamental da arquitetura MVC (se referem so ‘C’ da sigla), e no Spring-webmcv não é diferente. Saber configurá-los e atribuí-los a suas chamadas específicas é muito importante no desenvolvimento da aplicação. Pensando nisso o Spring disponibiliza várias implementações de controllers que pode ajudar no dia-a-dia e várias ferramentas para associar as chamadas a tais controllers. Como o objetivo do post é tratar da configuração por anotações, não entrarei no detalhe de tais implementações e de tais associações. Iremos utilizar um serviço qualquer da aplicação para servir de controller, e a associação será feita através das anotações.
Para tornar uma classe um controller do spring, basta anotá-lo com @Controller da seguinte forma:
[cc_java]
package br.com.;
@Controller
public class ServicoComum {
[/cc_java]
Repare que não é necessário extender nem implementar nenhuma classe ou interface específica, o que colabora bastante para desacoplar a lógica de view de nosso sistema.
Para habilitar esse nosso controller e associá-lo ao servlet, basta pedirmos ao Spring para scannear esse pacote e deixar o bean disponível no contexto do servlet. Para fazer isso adicione o seguinte no arquivo de beans do servlet:
[cc_xml]
[/cc_xml]
Perceba que coloquei a tag do contexto do spring que habilita a configuração por anotações.
Agora precisamos definir um método para que o spring faça a chamada quando o request chegar na aplicação. Para isso vamos entender o papel do ModelAndView.
ModelAndView
O ModelAndView é responsável por descrever o modelo e a view (intuitivo? ;)) daquela chamada, portanto nele estão setados a view a qual a chamada está associada, e todos os atributos de modelo que devem chegar até a view. Tais atributos são guardados como em um Map associando chaves e valores. Veremos que esses valores ficam disponíveis em nossa view e podem ser usados nos JSPs da aplicação, mas agora vamos ao método do controller:
[cc_java]
@RequestMapping(value = “/chamada”, method = RequestMethod.GET)
public ModelAndView trataChamada(@PathVariable(“var”) String var) {
[/cc_java]
Muita coisa acontecendo aqui, mas vamos por partes. A primeira coisa a se notar é que o método irá tratar todas as chamadas feitas em nomeDaAplicação/chamada, isso porque nosso servlet está associado em / e nosso método está associado com chamada. Nós poderíamos também ter definido o caminha básico para o controller ainda na anotação do controller, por exemplo:
[cc_java]
@Controller(“/base”)
public class ServicoComum {
[/cc_java]
Assim nosso método trataria todas as chamadas feitas em nomeDaAplicação/base/chamada.
A segunda coisa a se notar é que nosso método só irá tratar requisições do tipo GET, podendo ser alterado para os outros tipos de requisição seguindo um modelo REST.
A terceira coisa a se notar é que nosso método devolve um ModelAndView, portanto saberemos a que view o DispatcherServlet irá direcionar, e também teremos alguns atributos do modelo disponíveis.
A última mas não menos importante, é que o método está esperando um parâmetro. Esse parâmetro foi anotado com @PathVariable, isso significa que a chamada ao controller deve esr da seguinte forma: nomeDaAplicação/chamada?var=teste e assim nosso método irá receber o valor teste. Faça alguns testes e repare que é possível configurar a obrigatoriedade do parâmetro, a validação do mesmo dentre outras coisas. Também poderíamos ter definido o parãmetro como @RequestParam, mas nesse caso a chamada deveria estar em um formato POST e o atributo deveria estar setado no request.
ViewResolver
A última configuração necessária para nossa aplicação funcionar é um ViewResolver. Vamos utilizar um bem simples para que possamos utilizar páginas em JSP em nossa aplicação. Para isso, basta adicionar o seguinte bean no contecto do servlet:
[cc_xml]
[/cc_xml]
O que fizemos, foi dizer ao view resolver, que ele deve buscar na pasta WEB-INF/jsp por nossos arquivos JSPs antes de renderizar as páginas de resposta. Também estamos dizendo, que ele deve procurar através do nome da view que o controller devolver, por exemplo, se nosso ModelAndView possuir uma view com nome pagina, o view resolver irá buscar por um arquivo com nome pagina.jsp para renderizá-lo com os atributos setados no ModelAndView.
Existem muitos tipos de view resolvers, e muitas maneiras de configurá-los, mas para uma primeira experiência com o framework essa configuração já é suficiente.
Por @Gust4v0_H4xx0r
Compartilhe isso:
