Artigo SQL Magazine 63 - Fragmentação no SQL Server 2005 - Parte 2

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Essa segunda parte foca o desenvolvimento de uma aplicação Web para atuar em conjunto com a estrutura distribuída.

Esse artigo faz parte da revista SQL Magazine edição 63. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

SQL Server

Fragmentação no SQL Server 2005 – Parte 2

Criando uma aplicação que acessa o sistema distribuído

 

O presente artigo dá continuidade à série de artigos que aborda o projeto de distribuição de dados publicado na edição anterior. Conforme citado na primeira parte, o projeto trata da distribuição de dados referentes à inscrição no vestibular de uma instituição de ensino. Na ocasião, tratamos os itens essenciais à distribuição dos dados entre diversas instâncias do SQL Server 2005.

Essa segunda parte foca o desenvolvimento de uma aplicação Web para atuar em conjunto com a estrutura distribuída. Nesse cenário, será apresentado o roteiro da criação do sistema Web que acessa o sistema distribuído desenvolvido em Java.

Visão geral do projeto

O projeto foi baseado na arquitetura MVC (Model View Controler), uma arquitetura muito usada atualmente no desenvolvimento de projetos de software. Trata-se de um padrão para elaboração de aplicações que considera diferentes camadas na composição do sistema, onde cada camada possui uma responsabilidade bem definida que a diferencia das demais. Isso permite que exista independência entre as camadas para o melhor reaproveitamento de código, fato que contribui para o aumento de eficiência, além de facilitar a manutenção e a ampliação do software. Em outras palavras, a arquitetura MVC facilita que o software evolua a cada nova necessidade. A Figura 1 ilustra as camadas da aplicação desenvolvidas para o nosso projeto.

 

Figura 1. As camadas definidas na aplicação

 

Não pretendemos discutir se a arquitetura escolhida é a melhor ou não, apenas dizer que ela representa uma possível maneira de implementar a aplicação. De forma resumida, o papel da cada uma das camadas no modelo MVC e que estão presentes em nossa aplicação é:

·        Model (Modelo): representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. Em nosso caso, a classe “Inscricao” mantém todos os dados que compõem a inscrição em si (nome do candidato, curso pretendido, etc.). Já a classe “InscricaoDAO” tem a responsabilidade de acessar o banco de dados para inserir os dados armazenados na classe “Inscricao”.

·        View (Visualização): basicamente essa camada define quais dados serão apresentados e de que maneira eles serão visualizados pelo usuário. Em nosso caso, existem cinco arquivos nessa camada: dois formulários em HTML e três páginas em JSP:

o            inscricao.html: contém os campos para entrada dos dados da inscrição;

o            consulta.html: permite que o usuário defina o tipo de consulta a ser visualizada;

o            inscricao.jsp: utiliza os recursos da classe “InscriçãoDAO” para inserir os dados do candidato, bem como emite uma mensagem de resposta informando o sucesso ou não da inscrição;

o            consulta.jsp: apresenta o resultado da execução da view definida no SQL Server;

o            consulta_inscricao.jsp: apresenta o resultado da execução da stored procedure definida no SQL Server.

·        Controller (Controle): define o comportamento da aplicação, isto é, atua como um concentrador que despacha a execução para diferentes páginas dependendo das ações do usuário. Dessa forma, as ações do usuário serão mapeadas para chamadas apropriadas dentro do modelo MVC. Em nosso projeto, o Controller se refere a uma servlet chamada VestibularServet.

 

Outro item importante se refere à classe BD responsável pelo acesso ao banco de dados. Todas as ações realizadas no banco de dados (inclusão, exclusão, alteração, consulta e acesso a views e stored procedures) passam por essa classe. Observe pela Figura 1 que a classe BD não foi alocada a nenhuma camada. Isso ocorre porque entendemos que seu papel é servir as camadas superiores, formando outra camada de acesso aos dados. Considerando ainda que o banco de dados chamado “vestibular” hospeda views, stored procedures, restrições e outros controles, podemos afirmar que o modelo aqui apresentado é composto na verdade por cinco camadas.

No decorrer do artigo serão fornecidos outros detalhes a respeito de cada um dos itens citados acima.

 

Ambiente de Desenvolvimento

Existe uma grande variedade de ambientes de desenvolvimento de aplicações Web e muitos frameworks disponíveis no mercado (Spring, Hibernate, etc.). Para tornar nossa aplicação mais original, optamos por não utilizar nenhum framework. Isso não quer dizer que somos contra a utilização de frameworks, muito pelo contrário, cada framework tem sua contribuição como agente facilitador no desenvolvimento das aplicações. Sendo assim, utilizamos apenas as classes Java acessando diretamente os objetos do SQL Server (view e stored procedure). Isso é essencial para aproveitarmos a estrutura criada no SQL Server descrita no artigo anterior. Além disso, a distribuição dos dados fica encapsulada no próprio banco de dados, isto é, para a aplicação tanto faz se o sistema é distribuído ou não, isso fica a cargo do banco de dados. As ferramentas usadas no desenvolvimento de nosso projeto foram:

·        Eclipse 3.4: ambiente de desenvolvimento de software gratuito, multiplataforma e multilinguagem mais utilizado no desenvolvimento de aplicações Java: http://www.eclipse.org.

·        TomCat 6.0: é o servidor de aplicação Java gratuito, isto é, um container de servlets: http://tomcat.apache.org/.

·        "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?