Customização de Software com Ênfase na Arquitetura MVC e Struts

Boa parte dos softwares atuais lidam com a questão da customização, conhecida também como personalização, o que significa modificar sua aplicação de modo que fique mais próxima às necessidades particulares de uma empresa ou de um processo qualquer. Só temos uma certeza, todo software passará por mudanças com o tempo, seja a longo ou curto prazo. A função do projetista é precaver essa situação de modo que essas modificações não se tornem tão dolorosas para empresa responsável pelo software.

Série: MVC e Regras de negócio

Pensando nisso, o engenheiro Chistopher Alexander e mais quatro autores escreveram suas experiências publicando a obra "Design Patterns: Elements of Reusable Object-Oriented Software", de 1995, que tenta descrever soluções de problemas geralmente encontrados em projetos de software. Segundo o autor, um dos padrões mais utilizados nos dias de hoje é o design pattern MVC, Model-View-Controller, que permite uma separação em forma de camadas com uso de componentes (OLIVEIRA, 2004).

A arquitetura MVC juntamente com o framework Struts, facilita e muito a vida do desenvolvedor, pelo falo de implementar o design pattern padrão MVC em Java, sua vantagem é através da separação em camadas, que possibilita implementar com maior facilidade e clareza questões programáticas de maior importância, sendo elas controle de segurança, persistência de dados e forma de apresentação, possibilitando assim, uma customização mais pacífica do software.

Design Pattern MVC

Um design pattern, no português “padrão de projeto” é, por definição, uma solução para um dado problema em um determinado contexto. Sua vantagem é a possibilidade de reutilização para resolver problemas já avaliados. Resumidamente, padrões de projeto descrevem soluções comuns de se fazerem às coisas, tornando modelos-exemplo. A identificação dos mesmos se dá ao longo do desenvolvimento de projetos, onde problemas repetitivos surgem e, obviamente, com soluções parecidas. Os padrões de projeto, em sua totalidade, apresentam determinadas características comuns: sua base se dá em experiências anteriores; são reutilizáveis; combinam táticas de design e melhores práticas; podem ser usados juntos a fim de resolver uma gama maior de problemas.

A arquitetura J2EE, já adiciona em sua estrutura o padrão chamado MVC - Model, View e Controller - que determina com clareza uma divisão entre camadas de visualização (View), controle (Controller) e lógica de negócio (Model) (RONDINI, 2008).

O modo de organização dos componentes dentro do padrão MVC, proporciona grande credibilidade. Além disso, facilita o desenvolvimento das aplicações, capacitando a implementação de problemas em cada componente isoladamente, permitindo assim, a permuta do componente sem que o sistema se altere totalmente. No caso de algum componente não funcionar, este problema poderá ser facilmente resolvido com a substituição do mesmo.

Através da separação dos componentes, suas implementações podem ser feitas separadamente, com plataformas e sistemas variados, tendo como exigência exclusiva, a definição das interfaces em meio os componentes, e a preservação das mesmas. Antes do MVC, os projetos tendiam a aliar estes projetos, o MVC divide estes objetos com objetivo de aumentar a sua reutilização e flexibilidade. Além de oferecer grande confiabilidade, uma de suas grandes vantagens é permitir o desenvolvimento de produtos reutilizáveis (JÚNIOR, 2008).

A camada de modelo, se responsabiliza em tratar a lógica do negócio e seu estado, as tecnologias utilizadas nessa camada, são os JavaBeans, e frequentemente, Enterprise JavaBeans e JDBC. Seu modelo compreende todos os objetos de negócio, onde sua lógica é implementada, e onde se deve suportar um conjunto de requisitos e funcionalidades do sistema, sem o acoplamento das partes relacionadas do fluxo da aplicação que correspondem ao Controle (SOUZA, 2002).

Já, a camada de visão, compreende os JSPs e os Servlets, que representam a visão da aplicação, envolvidos na geração da interface com o usuário ou com outros sistemas, sua responsabilidade é manter a interface gráfica da aplicação, essa camada não possui lógicas de negócio, portanto todo o processamento é feito pelo modelo e então repassada para a visão (COSTA, 2008).

Por fim, a camada de controle funciona como intermediário entre as camadas modelo e visão, sua função é coordenar o envio e o recebimento de requisições entre as camadas de apresentação e negócio. Seus componentes têm por responsabilidade o fluxo da aplicação em questão, em sua normalidade, há a existência de um controlador para cada conjunto de funcionalidades relacionadas. Essa camada seleciona uma visualização para ser exibida como elemento da resposta a requisição do usuário (ROHLOFF, 2007, p. 11).

Além de exigir pessoal especializado, a arquitetura MVC requer um tempo maior de análise e de modelagem de seu sistema. Apesar da separação dos aspectos da apresentação, da camada de modelo, e da apresentação, a quantidade de classes pode ter um aumento significativo com o uso desse padrão. Mas esses paradigmas são quebrados quando levamos em consideração a vasta quantidade de vantagens oferecidas por essa arquitetura, como a de um desenvolvimento e manutenção com maior eficiência, providos de uma implementação onde seus componentes se isolam, oferecendo assim, extrema confiabilidade.

Foram citadas apenas algumas vantagens e desvantagens desse padrão, em si, a separação em camadas é o principal papel dessa arquitetura, onde a se visa a organização e facilidade quando trabalhamos com os componentes em suas camadas.

Struts Framework

Utilizado para implementar a arquitetura MVC em grandes aplicações, o Struts Framework é um projeto Jakarta open-source, mantido pela Apache Software Fundation que tem por objetivo oferecer um auxílio para construção de aplicações voltadas para o ambiente web. Ele foi criado por Craig McClanahan em maio de 2000, e desenvolvido com a colaboração de desenvolvedores voluntários, e vem sendo melhorado pela comunidade open-source desde então.

Tornou-se um padrão no mercado de desenvolvimento de softwares, e cada vez a procura por profissionais com o conhecimento nesse framework aumentará, o Struts está disponível sobre a licença "free-to-use-license" da Apache Software Foundation.

O aspecto mais poderoso da estrutura do framework, é sua sustentação para criação e processamento de formulários, ele favorece o desenvolvimento de aplicações, fornecendo um componente de controlador que se integra com outras tecnologias, para oferecer suporte aos componentes modelo, como por exemplo JDBC e EJB’s, e visão, como JSP e XSLT.

Através de um browser navegador, o usuário faz uma solicitação via url, como por exemplo, http://localhost:8080/arquivo.do. Note que no final existe a extensão .do que é utilizada no struts sob responsabilidade de invocar (mapear) o servlet controlador do struts, chamado struts-config.xml. Na primeira solicitação ao container, o método init() da ActionServlet (controlador do struts) no qual irá carregar as configurações do arquivo struts-config.xml em estruturas de dados localizadas na memória. Esta passagem só será executada uma única vez, pois nas solicitações seguintes, a servlet consulta estas estruturas na memória para definir o fluxo a ser seguido.

Com base na configuração do arquivo struts-config.xml, que a partir da solicitação inicial já se encontra carregado em estruturas de memória, o ActionServlet identificará qual será a classe de validação de dados (ActionForm) que será invocada. Através do método validate() da classe ActionForm, será verificada a integridade dos dados que foram recebidos na solicitação que vem do navegador. O controle é retomado pelo ActionServlet, que por sua vez, verifica o resultado da verificação feita pela classe ActionForm, sendo um resultado válido, o controlador passa para o passo seguinte (Action), caso contrário, o usuário receberá uma mensagem informando o motivo no qual sua solicitação não pode ser concluída.

Com base na configuração do arquivo struts-config.xml, que a partir da solicitação inicial já se encontra carregado em estruturas de memória, o ActionServlet identificará qual será a classe de validação de dados (ActionForm) que será invocada. Através do método validate() da classe ActionForm, será verificada a integridade dos dados que foram recebidos na solicitação que vem do navegador. O controle é retomado pelo ActionServlet, que por sua vez, verifica o resultado da verificação feita pela classe ActionForm, sendo um resultado válido, o controlador passa para o passo seguinte (Action), caso contrário, o usuário receberá uma mensagem informando o motivo no qual sua solicitação não pode ser concluída.

Baseado no fluxo da aplicação, o ActionServlet invoca uma classe Action, essas classes passarão pelo método execute() que irá delegar a requisição para a camada de negócio. A camada de negócio se responsabiliza em executar algum processo, tendo como utilização do resultado a exibição dos dados na camada de apresentação.

Quando o controle do fluxo da aplicação voltar ao Action responsável pela invocação do processo da camada de negócio, seu resultado será analisado e por consequente será definido qual o mapa adotado para o fluxo da aplicação. Neste ponto, os objetos que foram agregados na camada de negócio serão “tachados” como atributos na seção do usuário.

Com base também no mapeamento feito pelo Action, o controller faz um forward para JSP apresentar os dados. Através dos objetos selecionados como atributos da seção do usuário, já na camada de apresentação, a montagem do HTML para o browser se faz em cima da consulta a esses objetos. Por etapa final, o HTML chega como resposta solicitada pelo usuário. O fluxo de todo esse processo é mostrado na FIGURA 1 (SOUZA, 2004).

Antes de utilizar o struts framework, é necessariamente preciso configurar seu ambiente para que o mesmo tenha conhecimento de como mapear todas as requisições por meio de uma determinada extensão do arquivo para a ActionServet do struts. Isso necessariamente deverá estar no arquivo web.xml, que se localiza abaixo do diretório WEB-INF de sua aplicação.

O passo seguinte, é configurar o arquivo principal do struts, o struts-config.xml . Enquanto o arquivo web.xml determina onde a requisição deve chegar, o struts- config.xml especifica precisamente o que vai ocorrer com ela. Especificamente nada acontece sem sua concessão ou seu conhecimento, é onde os mapeamentos são definidos. Toda a navegação da aplicação está específica nesse arquivo, o que é uma grande vantagem, pois a conserva modularizada e de fácil manutenção. Todo esse arquivo é lido no momento em que o servidor é iniciado e é armazenado na memória, por questões de desempenho.

Além disso, é extremamente necessário que se tenha todos os arquivos .jar necessários à aplicação abaixo do diretório WEB-INF/lib, e todos os descritores de custom-tag’s abaixo do diretório WEB-INF (COSTA, 2008).

Conclusão

Este artigo apresenta uma opção de personalização de software, baseado na utilização do padrão MVC, juntamente com o framework Struts. Vale a pena lembrar que, quando realizada pela empresa fabricante do software, a customização pode significar uma fonte de renda, já para outras, prejuízo. Quando há a possibilidade de agregar seu produto a uma rede de serviços capaz de implementá-lo sem modificar o produto, considera-se uma fonte de renda. Já quando a exigência de customização não pode ser seguida pelo fornecedor, devido à falta de recursos, ou quando se tem uma versão diferenciada do produto para cada cliente, considera-se prejuízo.

O padrão MVC expõe conhecimentos relacionados à construção de software, conhecimento este, que foi ganho por especialistas em muitos anos. Desenvolvedores em geral, deveriam ser capazes de utilizar o padrão de projeto MVC de forma efetiva, sendo assim, pode-se comemorar a inteligência humana que os padrões refletem, tanto em cada padrão isoladamente quanto nos padrões em sua maioria.

para desenvolver aplicações simples e de pequeno porte, a utilização de uma arquitetura tão complexa e modular como o MVC talvez não seja tão vantajosa, sendo que, a maioria de seus benefícios são alcançados em aplicações corporativas de grande porte.