Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

FERNANDO ANTONIO BARBEIRO CAMPOS
LEONARDO BALDUINO SANTUCI

ESTUDO DE APLICABILIDADE DO PADRÃO MVC

Trabalho de Conclusão de Curso apresentado
como exigência parcial, para a obtenção do
grau no curso de Ciência da Computação, da
Universidade de Franca.

Orientador: Prof. Dr. Daniel Facciolo Pires

FRANCA
2009

FERNANDO ANTONIO BARBEIRO CAMPOS
LEONARDO BALDUINO SANTUCI

ESTUDO DE APLICABILIDADE DO PADRÃO MVC

Orientador:
Nome: Prof. Dr. Daniel Facciolo Pires
Instituição: Universidade de Franca.

Examinador(a):
Nome:
Instituição:

Examinador(a):
Nome:
Instituição:

Franca, _____/ _____ / _____

DEDICO este trabalho aos meus pais, Maria Aparecida e Reinaldo,
pela educação, afeto, ensinamentos e por acreditarem
incondicionalmente em meus sonhos;
à minha tia Marinda e minha avó Palmira por terem sempre me
acolhido como filho;
à minha namorada Lidiane, pelo amor, atenção e compreensão em
todos os momentos.

DEDICO este estudo aos meus pais, Benvindo e Celma, pelo amor
sem medida, pela educação e ensinamentos que muito me auxiliaram
dando-me base necessária para vencer esta e todas as etapas que
estão por vir;
às minhas irmãs, Érica e Lívia, pela amizade e apoio;
à minha namorada Bruna, pelo amor e companheirismo.

AGRADEÇO primeiramente a Deus, por ter proporcionado saúde,
paz e sabedoria;
ao nosso orientador e amigo Daniel Facciolo Pires pela dedicação,
paciência e, sobretudo, por ter nos amparado com seu profundo
conhecimento durante todo o estudo;
A Universidade de Franca, englobando todo corpo docente do curso
de Ciência da Computação, todas as pessoas do Centro Discente de
Informática e todos os colaboradores em geral;
aos meus amigos e colegas pelos excelentes e indispensáveis
momentos de descontração e apoio;
a todos que contribuíram de forma direta ou indireta para a
realização deste trabalho.

AGRADEÇO à Deus pela possibilidade de estar realizando mais esta
etapa em minha vida;
à todo o corpo docente da Universidade de Franca, por todo o
conhecimento compartilhado, em especial ao nosso orientador Daniel
Facciolo Pires pelo total apoio, não apenas neste trabalho, mas em
todos os passos que nos trouxeram até aqui;
à toda minha família, em especial à minha mãe pelo amor e suporte
que possibilitou e motivou a superação de mais esta etapa;
à minha namorada pelo amor, companheirismo e compreensão.

Divide as dificuldades que tenhas de examinar em tantas partes
quantas for possível, para uma melhor solução.
René Descartes

RESUMO

CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de
aplicabilidade do padrão MVC. 2009. 111 f. Trabalho de Conclusão de Curso (Graduação
em Ciência da Computação) – Universidade de Franca, Franca.

Este trabalho propõe uma pesquisa sobre padrões de projeto, com ênfase no padrão MVC.
Inicialmente, foi realizado um levantamento bibliográfico para a obtenção de conhecimento
sobre todos os aspectos que envolvem os conceitos e utilização de padrões de projeto, a partir
disto, são estudados frameworks e a plataforma JEE. Em busca de soluções para as
necessidades dos clientes de software (ressaltando disponibilidade e os requisitos altamente
mutáveis) e como prova de conceito da pesquisa, é definido como estudo de caso um sistema
baseado nos requisitos de um CRM (Customer Relationship Management) operacional que
deve possuir suas funcionalidades disponíveis através de diferentes dispositivos: web, desktop
e mobile. Em seguida, o software foi implementado em Java (JSE, JME e JEE) a partir do
ambiente de desenvolvimento Netbeans 6.5.1, seguindo a modelagem de dados definida pela
UML e fazendo uso do SGBD MySQL como dispositivo de armazenamento de dados. O
resultado foi uma aplicação melhor construída e comprovadamente mais fácil de manter e
expandir, que demonstra de forma eficaz o uso do padrão MVC. A partir de uma mesma
camada de modelo, foram desenvolvidos os três diferentes aplicativos definidos, onde o
aplicativo voltado para web é o que contém a maior parte das funcionalidades. O produto
obtido apresentou melhor qualidade, sendo que esta característica esteve envolvida em todas
as etapas de desenvolvimento.

Palavras-chave: Model-View-Controller, Padrões de Projeto, JAVA EE.

ABSTRACT

CAMPOS, Fernando Antonio Barbeiro; SANTUCI, Leonardo Balduino. Estudo de
aplicabilidade do padrão MVC. 2009. 111 f. Trabalho de Conclusão de Curso (Graduação
em Ciência da Computação) – Universidade de Franca, Franca.

This paper proposes a research about design patterns, with emphasis on the MVC pattern.
Initially, had been performed a literature review to obtain knowledge of all aspects that
involves the concepts and use of the design patterns, then frameworks and JEE platform were
studied. In searching for solutions to the needs of software customers (emphasizing
availability and highly changeable conditions) and as proof of concept research, a case of
study about a system was defined based on the requirements of a CRM (Customer
Relationship Management) operational that must have available functionalities through
different devices: web, desktop and mobile. Then, the software was implemented in Java
(JSE, JEE, and JME) from the development environment Netbeans 6.5.1, following the
modeling data defined by UML and using the MySQL DBMS as a storage device data. The
result was a better built application, easier to maintain and expand that effectively
demonstrates the use of the MVC pattern. From a single layer model, had been developed the
three different defined applications, where the web application-oriented contains the most
features. The product showed better quality, and this characteristic had been involved in all
stages of the development.

Key words: Model-View-Controller, Design Patterns, JAVA EE.

LISTA DE ABREVIATURAS

MVC Model-View-Controller

JEE Java Enterprise Edition

CRM Customer Relationship Management

JSE Java Standard Edition

JME Java Micro Edition

UML Linguagem de Modelagem Unificada

JSF Java Server Faces

GUI Interface Gráfica dos Usuários

JSP Java Server Pages

IDE Integrated Development Environment

SGBD Sistema Gerenciador de Base de Dados

JDK Java Development Kit

OOPSLA Object-Oriented Programming, Systems, Languages, and Applications

GoF Gang of Four

ORM Mapeamento Objeto-Relacional

DAO Objeto de Acesso a Dados

HTML Linguagem de Marcação de Hipertexto

ASP Active Server Pages

PHP Personal Home Page

HTTP Protocolo de Transferência de Hipertexto

ASF Apache Software Foundation

XML Linguagem de Marcação Extensível

API Interface de Programação de Aplicativos

AOP Programação Orientada a Aspectos

EJB Enterprise JavaBeans

JDO Java Data Objects

JDBC Java DataBase Connectivity

JNDI Java Naming and Directory Information

AJAX Asynchronous JavaScript and XHTML

PDF Portable Document Format

XSTL Extensible Stylesheet Language Transformation

UI Interface do Usuário

POJO Plain Old Java Object

JCP Java Community Process

CORBA Common Object Request Broker Architecture

EIS Enterprise Information System

B2B Business-to-Business

LAMP Linux, Apache, Mysql e PHP

LADP Linux, Apache, Database e PHP

CRUD Create, Retrieve, Update and Delete

SQL Structured Query Language

SOAP Simple Object Access Protocol

WSDL Web Service Description Language

URL Universal Resource Location

LISTA DE FIGURAS

Figura 1 – Padrão MVC aplicado para GUI e tecnologias
Servlet/JSP. 27

Figura 2 – Exemplo de um modelo representado por diferentes
views (visões). 29

Figura 3 – Esquema de uma aplicação que deve suportar
diversos tipos de usuários e interfaces. 29

Figura 4 – Versão tradicional do MVC. 31

Figura 5 – Versão do MVC web (MVC Model2). 32

Figura 6 – Aplicação desenvolvida com uso de um framework. 36

Figura 7 – Visão geral do framework Spring. 40

Figura 8 – Arquitetura JSF baseada no modelo MVC. 43

Figura 9 – Contêiner JEE. 49

Figura 10 – Diagrama de casos de uso. 61

Figura 11 – Diagrama de classes. 62

Figura 12 – Diagrama de componentes. 63

Figura 13 – Diagrama de entidade-relacionamento. 64

Figura 14 – Representação do CRM_Library (camada modelo). 67

Figura 15 – Utilização do modelo nos outros projetos. 70

Figura 16 – Representação do CRM_Web (camadas de controle e
visão). 72

Figura 17 – Aplicativo em execução (tela de login). 74

Figura 18 – Tela inicial (usuário de perfil auxiliar). 75

Figura 19 – Tela inicial (usuário de perfil intermediário). 75

Figura 20 – Tela inicial (usuário de perfil administrador). 76

Figura 21 – Tela de cadastro de relatos (acessível por qualquer
perfil). 77

Figura 22 – Visualização de relatos (acessível por qualquer
perfil). 79

Figura 23 – Tela de envio de mensagens (acessível por perfil
intermediário ou superior). 80

Figura 24 – Visualização de mensagens (acessível por perfil
intermediário ou superior). 80

Figura 25 – Tela de cadastro de cobranças (acessível por perfil
administrador). 81

Figura 26 – Visualização de cadastro de cobranças (acessível por
perfil administrador). 81

Figura 27 – Classes do projeto CRM_Desktop. 82

Figura 28 – Desenvolvimento de janela com o NetBeans. 83

Figura 29 – Tela de login do aplicativo desktop. 84

Figura 30 – Tela principal aplicativo desktop. 85

Figura 31 – Botões de navegação entre os registros. 86

Figura 32 – Edição de registro de usuário. 86

Figura 33 – Exclusão de registro de usuário. 87

Figura 34 – Classe web service. 88

Figura 35 – Teste de um serviço web. 89

Figura 36 – Representação do CRM_Mobile. 90

Figura 37 – Criação de um cliente de serviços web em Java ME. 91

Figura 38 – Execução do CRM_Mobile. 93

Figura 39 – Tela de busca. 94

Figura 40 – Confirmar conexão com web service. 94

Figura 41 – Busca efetuada com sucesso. 95

SUMÁRIO

INTRODUÇÃO .................................................................................................................. 13
1 PADRÕES DE PROJETO ................................................................................ 16
1.1 CONSIDERAÇÕES INICIAIS ............................................................................ 16
1.2 DEFINIÇÃO ........................................................................................................ 16
1.3 ORIGEM .............................................................................................................. 17
1.4 EVOLUÇÃO ........................................................................................................ 18
1.4.1 Arquitetura de Camadas ....................................................................................... 19
1.4.2 Programação Orientada a Objetos ........................................................................ 21
1.5 REUTILIZAÇÃO ................................................................................................ 22
1.6 CLASSIFICAÇÃO .............................................................................................. 23
1.7 CONSIDERAÇÕES FINAIS ............................................................................... 24
2 MVC (MODEL-VIEW-CONTROLLER) ....................................................... 25
2.2 SURGIMENTO ................................................................................................... 25
2.3 APLICAÇÃO ....................................................................................................... 26
2.3.1 Vantagens e Desvantagens ................................................................................... 27
2.4 COMPONENTES DO PADRÃO MVC .............................................................. 30
2.4.1 Modelo (Model) ................................................................................................... 32
2.4.2 Visão (View) ........................................................................................................ 33
2.4.3 Controlador (Controller) ...................................................................................... 34
2.5 FRAMEWORKS ................................................................................................. 35
2.5.1 Struts .................................................................................................................... 37
2.5.2 VRaptor ................................................................................................................ 38
2.5.3 Spring ................................................................................................................... 39
2.5.4 WebWork ............................................................................................................. 41
2.5.5 JSF (Java Server Faces) ....................................................................................... 42
2.6 JEE (JAVA ENTERPRISE EDITION) ............................................................... 47
2.6.1 Arquitetura ........................................................................................................... 48

2.6.2 Componentes ........................................................................................................ 50
2.6.2.1 Implementação de Componentes Web ................................................................. 51
2.6.2.2 Implementação de Componentes de Negócio ...................................................... 54
2.6.3 Comparativo com outras tecnologias ................................................................... 53
3 ESTUDO DE CASO ........................................................................................... 57
3.2 MODELAGEM DO PROJETO ........................................................................... 57
3.2.1 Descrição narrativa do sistema ............................................................................ 58
3.2.2 Especificação dos requisitos do sistema .............................................................. 59
3.2.3 Diagrama de casos de uso do sistema .................................................................. 60
3.2.4 Diagrama de classes ............................................................................................. 62
3.2.5 Diagrama de componentes ................................................................................... 62
3.2.6 Diagrama de entidade-relacionamento ................................................................. 64
4 IMPLEMENTAÇÃO DO ESTUDO DE CASO .............................................. 66
4.2 DESENVOLVIMENTO DA CAMADA MODELO CRM LIBRARY .............. 66
4.2.1 Pacote br.crm.model.entities ................................................................................ 68
4.2.2 Pacote br.crm.model.dao ...................................................................................... 68
4.2.3 Pacote br.crm.model.dao.implementation ............................................................ 69
4.2.4 Conceitos da utilização do modelo na aplicação ................................................. 70
4.3 DESENVOLVIMENTO DO APLICATIVO CRM WEB.................................... 70
4.3.1 Pacote br.crm.web.controller ............................................................................... 72
4.3.2 Pacote br.crm.web.phaselistener .......................................................................... 73
4.3.3 Implementação da visão do sistema ..................................................................... 74
4.4 EXECUÇÃO DO APLICATIVO CRM WEB .................................................... 74
4.4.1 Funcionalidades disponíveis para o perfil Auxiliar ............................................. 76
4.4.2 Funcionalidades disponíveis para o perfil Intermediário ..................................... 79
4.4.3 Funcionalidades disponíveis para o perfil Administrador ................................... 80
4.5 DESENVOLVIMENTO DO APLICATIVO CRM DESKTOP ......................... 82
4.6 EXECUÇÃO DO APLICATIVO CRM DESKTOP ........................................... 84
4.7 DESENVOLVIMENTO DO WEB SERVICE MOBILE WS ............................ 87
4.8 EXECUÇÃO DE TESTES DO WEB SERVICE ................................................ 89

4.9 DESENVOLVIMENTO DO APLICATIVO CRM MOBILE ............................ 89
4.9.1 Pacote br.crm.mobile.controller.ws ..................................................................... 90
4.9.2 Pacote br.crm.mobile.view ................................................................................... 92
4.10 EXECUÇÃO DO APLICATIVO CRM MOBILE .............................................. 92
CONCLUSÃO ..................................................................................................................... 96
REFERÊNCIAS ................................................................................................................. 98
GLOSSÁRIO ..................................................................................................................... 102

13

INTRODUÇÃO

O uso de softwares para atender as mais variadas necessidades cotidianas de
pessoas e organizações é algo já consolidado, mas ainda crescente.
Com a importância e tendência corrente que os softwares possuem na gestão de
informações e auxílio na tomada de decisões estratégicas, estes não poderiam ser produtos
construídos sem a adoção de metodologias que garantam um padrão de qualidade e o total
atendimento dos requisitos presentes e futuros dos usuários.
Além disto, o desejo pela chamada computação ubíqua, que se pode entender
por “computação em qualquer lugar”, impulsiona o desenvolvimento de aplicações amigáveis
para web, o que acarreta na maior incidência de servidores de aplicativos, provedores de
serviços e constante aprimoramento e evolução no que diz respeito a construção de aplicativos
em n camadas,
Assim, o panorama é que as informações fiquem disponíveis em qualquer
computador com acesso a internet, mas a evolução constante e o verdadeiro sentido da
computação ubíqua levam as pessoas a pensarem em aplicações que rodem em qualquer
dispositivo, seja ele um computador pessoal, notebook ou qualquer dispositivo móvel que
uma pessoa possa levar consigo.
Acrescenta-se ainda as características de alta mutação no requisitos de
usuários, ou seja, por melhor que seja definida a especificação de requisitos, os mesmo
mudam constantemente de acordo com necessidades diferenciadas da empresa e dos usuários
deste software.
Neste contexto, os padrões de projeto são cada vez mais tratados com
naturalidade em projetos diversificados. Seguir práticas que deram certo e foram bem-
sucedidas, significa não necessitar reinventar soluções para um domínio de problema já
observado.
Também o conceito de desenvolvimento em camadas citado, resultado de uma
evolução histórica no desenvolvimento de softwares, é implementado pelo MVC, que divide
os componentes de um sistema em Model (Modelo), View (Visão) e Controller (Controle),
deixando-o mais modularizado e fracamente acoplado.

14

Nesse cenário, o padrão MVC tornou-se amplamente adotado para divisão de
sistemas em diversos componentes, tal qual o nome sugere, onde cada componente tem suas
funcionalidades específicas. Assim, atinge-se um projeto extremamente manutenível.
Acresce-se a possibilidade de trabalhar paralelamente com equipes de
desenvolvimento, cada qual criando soluções para uma camada distinta da aplicação. Esse
método resulta em um software seguro, flexível, disponível (afinal, foi desenvolvido por
especialistas em uma dada categoria do desenvolvimento) de forma muito mais ágil (várias
equipes trabalham em um tempo mais reduzido) e que sempre atenda aos requisitos dos
usuários.
Portanto, trazer ciência e avaliar os padrões de projeto e como eles ajudam a
atender as necessidades e desejos citados são extremamente importantes no processo de
desenvolvimento de software.
Como principal objetivo com este trabalho visa investigar, explorar e levar ao
conhecimento os padrões de projeto, em especial o MVC, e como eles podem ser utilizados e
combinados para resolver um problema sob um determinado domínio. Mais especificamente,
é feito um estudo da aplicabilidade do padrão MVC no desenvolvimento de aplicações web
com a plataforma JEE e frameworks que auxiliam nesta construção, por exemplo, Spring,
VRaptor, Struts, WebWork e JSF (Java Server Faces) que é o utilizado no estudo de caso.
Para demonstrar como é possível construir aplicações robustas, manuteníveis,
expansíveis e acessíveis com o padrão MVC, desenvolve-se um estudo de caso baseado nos
requisitos de um CRM (Customer Relationship Management) operacional. Neste estudo de
caso, mostra-se que a partir de uma mesma camada de modelo de software, podem-se criar
aplicativos para diferentes dispositivos, como desktop, web e dispositivos móveis.
Inicialmente, toda a pesquisa é baseada em levantamento bibliográfico para
obtenção da base de conhecimento necessária para desenvolver todo o conteúdo. Como estudo
de caso, é definido um software fundamentado nos requisitos de um CRM (Customer
Relationship Management) operacional que, com o auxílio da ferramenta JUDE e embasado
na UML (Linguagem de Modelagem Unificada), teve definido sua especificação, análise e
documentação do sistema.
Completando a gama de ferramentas utilizadas, como dispositivo de
armazenamento dos dados da aplicação foi adotado o SGDB (Sistema Gerenciador de Banco
de Dados) MySQL e a implementação do software em si, foi apoiada pela ferramenta
NetBeans IDE (Integrated Development Environment) em conjunto com o JDK (Java
Development Kit). Logo, o projeto foi implementado sobre especificações da linguagem Java

15

(JSE, JME e JEE), fazendo-se necessário o uso de frameworks e pacotes, como JSF (Java
Server Faces) e Swing.
Definidas essas características, faz-se necessário delinear a estruturação do
trabalho. O mesmo divide-se em quatro capítulos, onde o primeiro abrange toda a parte de
padrão de projetos em geral, desde o seu surgimento, até a motivação de seu uso, suas
classificações, entre outros. O segundo capítulo trata uma visão minuciosa do padrão MVC
em si, que é o foco de estudo da pesquisa. O terceiro capítulo traz consigo a definição do
estudo de caso e a modelagem da solução proposta. Por fim, o último capítulo apresenta a
implementação e resultados obtidos.

16

1 PADRÕES DE PROJETO

1.1 CONSIDERAÇÕES INICIAIS

Este capítulo demonstra os padrões de projeto, passando por seu contexto
histórico e evolutivo de forma a descrever sua classificação, o progresso na construção de
software e as melhorias que os padrões podem agregar aos projetos da atualidade.

1.2 DEFINIÇÃO

Padrões de projeto no desenvolvimento de software, como citam Gamma et al.
(2000), são como um gabarito que podem ser aplicados para diversas soluções, é importante
notar que um padrão não é uma mera implementação pronta de um projeto específico
orientado a objetos, mas sim uma definição abstrata que indica os métodos que devem ser
seguidos alcançando um objetivo.
Um erro comum de desenvolvedores sem experiência é tentar traçar um árduo
caminho construindo uma aplicação por inteiro. Enquanto que projetistas experientes tomam
por base sucessos em aplicações que já estão desenvolvidas para encaixar sua solução no
novo domínio que está sendo tratado. Esse é um exemplo da utilização de padrões onde, a
partir de uma boa documentação de software e gestão de atividades, os desenvolvedores
podem reutilizar suas soluções em uma vasta gama de situações.
Gamma et al. (2000) citam também que existem quatro elementos essenciais
para definir um padrão de projeto, são eles:
• Nome do padrão: O nome deve descrever de forma sucinta os
objetivos, problemas em que o padrão se aplica, as soluções e as
conseqüências de se aplicar tal padrão, ou seja, o nome deve fornecer
uma visão geral do padrão com poucas palavras. O nome é de difícil
definição pela importância que ele tem, contudo, definido o nome ele

17

permite que as pessoas envolvidas no desenvolvimento tenham
facilidade em debater as soluções propostas.
• Problema: Descreve o contexto onde o padrão pode ser aplicado e pode
conter uma pequena lista com condições que devem ser enquadradas
para optar ou não pelo uso de tal padrão.
• Solução: Algumas pessoas com pouca experiência no tema podem
confundir-se com o termo solução. Ela não é uma implementação
específica para um domínio em particular, até porque um tipo de
solução pode ser aplicado em diferentes âmbitos. Entretanto, uma
solução deve fornecer uma visão abstrata de como solucionar o
problema e como organizar os elementos para essa resolução.
• Conseqüências: Serve para aferir qual o custo-benefício de aplicar-se o
padrão, avaliando se sua utilização favoreceu e engrandeceu o projeto,
ou então se esta utilização foi onerosa para o mesmo.

1.3 ORIGEM

O conceito dos padrões de projeto teve como pioneiro o arquiteto austríaco
Christopher Alexander. Ele concebeu a idéia de documentar suas experiências em projetos de
arquitetura e urbanismo na forma de padrões.
Christopher buscou encontrar quais eram os pontos em comum entre os
projetos considerados de alto nível, e documentar estes pontos, para que pudessem ser
seguidos em projetos posteriores.
Entre as décadas de 60 e 70, ele escreveu livros e artigos em universidades
norte-americanas. Na obra “A Pattern Language: Towns, Buildings, Constructions”
(ALEXANDER, 1977 apud GAMMA et al., 2000, p. 10), onde cita que: “cada padrão
descreve um problema no nosso ambiente e o cerne de sua solução, de tal forma que se possa
usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira”. Essa
citação, ainda que direcionada à arquitetura, é extremamente adequada aos padrões de projeto
no desenvolvimento de software.

18

Entende-se que, ao adotar um padrão para a resolução de um determinado
problema, está se utilizando uma solução que já foi aplicada e possui uma eficiência
comprovada.
Alguns anos após os estudos do arquiteto, mais precisamente no ano de 1987,
em uma conferência sobre programação orientada a objetos, a OOPSLA (Object-Oriented
Programming, Systems, Languages, and Applications), os pesquisadores Kent Beck e Ward
Cunningham apresentaram um conjunto reduzido de padrões para o desenvolvimento de
software na linguagem Smalltalk, focando o uso em projetos com janelas.
Posteriormente, na década de 90, Erich Gamma, em sua tese de doutorado,
realizou estudos sobre padrões de projetos orientados a objetos visando à utilização de
interfaces gráficas. Com isso, Erich aproximou-se a Richard Helm e mais tarde a Ralph
Johnson e John Vlissides, formando assim a conhecida “gangue dos quatro” (Gang of Four)
que é responsável pelo precursor e um dos principais livros do assunto, o “Design Patterns:
Elements of Reusable Object-Oriented Software”, publicado em 1994. Tal livro é um
verdadeiro catálogo sobre os padrões da época e traça suas características principais.
Visando sanar as dificuldades comuns na criação de softwares orientados a
objetos (desenvolver soluções reutilizáveis, de qualidade, de fácil manutenção e expansão), a
Gangue dos Quatro escreveu este livro documentando e catalogando as melhores soluções que
vinham sendo adotadas nos projetos orientados a objetos, porém, sem registros formais das
soluções, o que implicava em uma redescoberta da solução sempre que se deparava com
algum problema.
Os padrões de projeto vieram para melhorar e aprimorar as vantagens dos
projetos orientados a objetos.

1.4 EVOLUÇÃO

O desenvolvimento de aplicações passou por grandes mudanças desde o
surgimento dos primeiros programas de computador. As mudanças mais notórias fazem
menção à troca de paradigmas, onde os algoritmos procedurais perderam espaço perante aos
programas de orientação a objeto. Este fato sem dúvida trata-se de uma constante evolução de
uma arquitetura em camadas, conforme descrito a seguir.

19

1.4.1 Arquitetura de camadas

Segundo Bond et al. (2003) o processo evolutivo das aplicações passa por
modelos de camadas, sejam elas físicas ou lógicas, tendo em mente que camadas físicas
tratam componentes e equipamentos diferentes, enquanto que camadas lógicas fazem menção
aos programas em si.
Ainda nas teorias de Bond et al. (2003), na época dos computadores de grande
porte existia uma grande centralização do processamento que acarretava na utilização de
programas escritos em um único bloco de código, instalados em uma única máquina. Esse
aglomerado de código incluindo todas as funcionalidades é o chamado código monolítico.
No código monolítico estavam concentrada a lógica de apresentação, lógica de
negócio e lógica de acesso a dados. Com isso, esses programas sofriam graves consequências
no que diz respeito à manutenção. Com as necessidades de mudanças, ao incluir
funcionalidades ao projeto, o grande código deveria ser recompilado por completo, podendo
ocasionar erros não esperados em outras partes (devido ao forte acoplamento) e uma série de
outros empecilhos.
Além disto, com o decorrer do tempo e da maior disseminação dos
computadores pessoais, surgiu a vontade de compartilhar dados entre duas ou mais máquinas.
A partir de então introduziu-se outra camada física, deixando a lógica de acesso a dados
separada das lógicas de apresentação e do negócio. Com isso, é necessária a existência de um
servidor de banco de dados que, teoricamente, pode ser substituído por outro, até com
SGBD’s (Sistema Gerenciador de Banco de Dados) diferentes.
Apesar da arquitetura implantada com duas camadas apresentar vantagens
sobre o código monolítico existem alguns pontos negativos que, de acordo com Bond et al.
(2003), devem ser observados, por exemplo:
• O cliente fica repleto de código da lógica de negócios e da lógica de
apresentação, sendo assim, o cliente torna-se um cliente ‘gordo’ (thick).
Isso implica em diversas deficiências, por exemplo, quando é
necessária uma atualização;

20

• Podem ocorrer situações onde o fornecedor, apesar de possuir um
código executável que já foi compilado, não se sinta completamente
seguro de deixar sua lógica de negócio na máquina cliente;
• Como há apenas um único módulo executável, a manutenção é
dificultada por uma necessidade de atualização e recompilação de todo
o projeto.
Com o advento da Internet e o surgimento da web, separar a lógica do negócio
da interface de apresentação do usuário tornou-se um desejo por parte dos usuários e também
dos desenvolvedores. Os clientes agora seriam apenas navegadores web, ou seja, clientes
‘magros’ (thin) que faz com que os usuários tenham acesso a diferentes aplicações disponíveis
em um mesmo software (o navegador).
Com isso, acrescentou-se uma nova camada física, separando então a lógica do
negócio da lógica de apresentação e da lógica de acesso a dados. O processamento, assim,
torna-se tarefa dos servidores web e isso torna extremamente vantajoso em diversos aspectos
como manutenção, fraca dependência entre o código (fraco acoplamento), modularidade e
escalabilidade.
Diante do cenário atual onde as necessidades de uma organização mudam com
uma incrível freqüência, esta organização de camadas parece fornecer um bom suporte para as
necessidades mutantes das empresas. Além disso, é importante salientar que os aplicativos
atuais devem fornecer alta disponibilidade, ou seja, permanecerem disponíveis sempre que
solicitados, mesmo que em condições adversas.
A escalabilidade é outro ponto favorável e ela implica que deve ser tolerado
um aumento no número de computadores que utilizam o programa, sem que o mesmo sofra
demasiadamente as conseqüências desta adição. O acréscimo destas máquinas não deve ser
muito trabalhoso e como no modelo de três camadas é necessário apenas um navegador para
acessar a aplicação, esse é o panorama mais adequado atualmente.
O processo de evolução constante exigiu uma maior sofisticação das
linguagens de programação e métricas de análise e modelagem de sistemas. Devido a essas
necessidades, a orientação a objetos ocupou um grande e importante espaço nos ambientes de
desenvolvimento devido aos seus poderosos recursos.

21

1.4.2 Programação Orientada a Objetos

O paradigma da orientação a objetos tenta modelar os elementos em um
sistema da mesma forma que são percebidos no mundo real. Desta forma, neste paradigma, os
sistemas são compostos por objetos que possuem responsabilidades e funções, e estes,
colaboram entre si para a realização de um objetivo comum. Porém, os projetos orientados a
objetos tendem a ser mais complexos e difíceis de modelar e implementar.
Os processos de modelagem de software tradicionais não preparam o software
para futuras modificações, eles descrevem apenas as necessidades presentes no levantamento
de requisitos observados no início do projeto. Por isto mudanças futuras tornam-se um grande
problema para os desenvolvedores, uma vez que modificações são difíceis de fazer e sempre
estão sujeitas a introduzir erros no sistema.
As mudanças de requisitos são uma questão inevitável, e por melhor que seja o
levantamento de requisitos iniciais, eles nunca atenderão a todas as necessidades do cliente,
por deficiência no levantamento de requisitos, ou simplesmente porque as necessidades do
cliente mudam.
Como citam Shalloway e Trott (2004, p. 34), “em vez de reclamar de requisitos
variáveis, devemos mudar o processo de desenvolvimento para que possamos realizar as
alterações de modo mais eficaz”. Mesmo com o poder que possui, o simples fato de adotar o
paradigma da orientação a objetos não é garantia de um software de qualidade e bem
estruturado. Os padrões de projeto descrevem formas eficientes de se construir aplicações
baseadas no paradigma da orientação a objetos que possuam uma boa engenharia e que sejam
manuteníveis e expansíveis.
Sistemas de software que não possuem uma separação bem definida entre as
partes, e mesmo entre as diversas responsabilidades de cada uma dessas partes, tornam-se
sistemas impossíveis de manter, devido à dificuldade que possuem para receberem mudanças.
Os padrões descrevem formas de desacoplar as partes de um sistema e tornar
essas partes totalmente independentes umas das outras. Eles abstraem o problema, de forma
que se tenha uma visão de alto nível do mesmo, podendo assim fazer uma melhor análise e
desenho do projeto. Possibilitam ainda, o estabelecimento de uma terminologia comum,
facilitando a comunicação entre aqueles que participam da criação de um software.

22

A adoção de padrões não se dá somente na implementação. De acordo com os
pensamentos de Shalloway e Trott (2004), os padrões podem ser adotados em todos os níveis
de um sistema, na análise, no projeto e, é claro, na implementação.

1.5 REUTILIZAÇÃO

O processo de construção de software é uma tarefa extremamente complexa.
Desenvolver algo a partir do zero é dispendioso e demorado, especialmente se for algo
grande. Deve ser feito um planejamento minucioso visando atender da melhor forma as
necessidades de um cliente.
Para otimizar este processo, o melhor recurso encontrado pelos projetistas e
desenvolvedores foi o reuso. Porém o reuso não é algo simples de realizar de forma efetiva e
eficiente.
Conforme a idéia de Gamma et al. (2000), o reuso é uma das necessidades dos
projetistas, aproveitando-se de experiências e projetos bem sucedidos anteriormente, captando
funcionalidades dos mesmos para utilizar em um novo domínio. Contudo, essa reutilização é
complexa e difícil de lidar, ainda que os projetos anteriores tenham sido desenvolvidos nos
melhores moldes da programação orientada a objetos.
Antes de se falar em orientação a objetos, as primeiras formas de reuso que
foram adotadas, em nível de implementação, foram a utilização de subrotinas e a criação de
bibliotecas. Nesse momento já surgia à necessidade de se criar abstrações das idéias. Os
trechos de código que eram repetitivos tinham seu objetivo principal abstraído e, se tornavam
uma subrotina que realizava sempre a mesma coisa. A mesma subrotina era chamada, porém
com parâmetros diferentes, assim ela realizava sempre a mesma função, mas sempre criando
resultados diferentes.
A orientação a objetos chegou e parecia resolver definitivamente o problema
da dificuldade do reuso. Recursos como a herança, o polimorfismo, agregações, composições,
possibilidade de ser criar pacotes de classes; de fato possibilitam o reuso, porém, apenas em
nível de implementação, e também requer um amplo conhecimento de todos estes conceitos
para que seja bem feito.
Neste caso, as dificuldades enfrentadas em lidar com o reuso de componentes
se dão em função das dependências existentes dentro de um programa completo, onde muitas

23

vezes um trecho é fortemente acoplado em outro dependendo de heranças e outras estruturas
da programação.
A idéia central dos padrões é seguir maneiras que levem ao desenvolvimento
baseado em abstração de soluções e isso acarreta diretamente em melhores práticas no
desenvolvimento, adotando modelos que deram certo.
Os padrões de projeto surgiram por meio da documentação formal de soluções
que vinham sendo utilizadas, afim de que as soluções não tivessem que ser redescobertas
sempre que se deparasse com um mesmo problema. De acordo com Sauvé (2006) não se
reutiliza o código, apenas as idéias.
Ainda de acordo com Sauvé (2006), os design patterns definem maneiras de
separar e isolar características que são comuns das que são distintas entre casos. É essa
separação que permite abstrair a idéia central da solução e fazer reuso dela em outro problema
sob o mesmo domínio.

1.6 CLASSIFICAÇÃO

Padrões ditam as melhores formas de se criar classes e objetos e como melhor
relacioná-los.
O livro base da ‘Gang of Four’ que é na verdade um dos principais catálogos
de padrões de projeto define, inicialmente, 23 padrões distintos para solucionar variados
problemas. Esses 23 padrões, contudo, permanecem divididos em três classificações iniciais,
são elas: padrões de projeto criacionais, padrões estruturais e padrões comportamentais. Essa
classificação nos dá uma abstração ainda maior sobre a solução a ser adotada para um
problema particular.
Os padrões criacionais descrevem formas de se criar e instanciar objetos, esta
categoria agrupa padrões de projeto como o Abstract Factory, Singleton, Double-Checked
Loking, Factory Method que podem ser usados em casos onde, por exemplo, apenas um
objeto de uma classe pode ser instanciado; não se sabe, em tempo de compilação, qual objeto
deverá ser instanciado, entre outras situações.
Os padrões estruturais apresentam formas para reunir os objetos existentes no
sistema, esta categoria agrupa padrões de projeto como o Facade, Adapter, Bridge e

24

Decorator que podem ser usados em casos onde, por exemplo, um objeto deve mascarar outro
objeto ou um subsistema; criar interfaces para que objetos distintos possam se comunicar.
Comportamentais descrevem a maneira como os componentes comunicam-se,
além de desvincular objetos no sistema para que este possa ser variável. Um exemplo nesse
sentido são os componentes que fornecem comportamento para interação com os usuários do
sistema. Alguns padrões que se enquadram como comportamentais são: Observer, Strategy,
Memento, State, entre outros.
Apesar das três classificações anteriormente citadas, com avanço da tecnologia
e surgimento de novas tendências, algumas novidades modificaram um pouco as disposições
dos padrões. Segundo Deitel (2005) há uma inclusão de padrões populares como é o caso dos
padrões de projeto que tratam a concorrência (multithreading) e ainda os padrões
arquitetônicos, como é o caso do MVC (Model-View-Controller).
Os padrões de concorrência tratam de casos onde se faz uso de processamento
paralelo através do uso de multithreading, descrevendo boas formas de uso para evitar
problemas pertinentes a estes tipos de sistemas.
Os padrões arquitetônicos descrevem formas de interligar partes de um sistema
de uma maneira que estas partes possam colaborar uma com a outra, porém sem que haja
dependência entre elas. O padrão MVC é classificado como um padrão arquitetônico. Sendo
este o foco principal deste trabalho.

1.7 CONSIDERAÇÕES FINAIS

Frequentemente, os padrões são adotados em projetos diversos e há um senso
comum de que a utilização dos mesmos implica em maiores benefícios durante o ciclo de vida
de uma aplicação.
Conhecer e aprofundar as informações a respeito das definições, características
e classificações destes padrões pode tornar o profissional diferente dentro do mercado e levá-
lo a um alto nível no desenvolvimento de software.
Os estudos formaram base de conhecimento sobre padrões de projeto de uma
forma geral para que fosse possível um melhor entendimento do padrão MVC
especificamente, que é o foco de pesquisa apresentado no próximo item.

25

2 MVC (MODEL-VIEW-CONTROLLER)

2.1 CONSIDERAÇÕES INICIAIS

O MVC (Model-View-Controller) é um padrão de projeto arquitetural baseado
em outros padrões como o Observer, Composite e Strategy. O MVC, como o nome sugere,
possibilita a separação de um projeto em múltiplas camadas, das quais fazem parte: Modelo
(Model), Visão (View) e Controlador (Controller). Este capítulo apresentará um estudo
aprofundado das características desse padrão, passando por uma conjuntura histórica e
explicando suas aplicações, frameworks, vantagens e desvantagens de sua utilização, entre
outros.
Além do MVC em si, o capítulo trará algumas considerações a respeito da
especificação JEE (Java Enterprise Edition) que é uma das tecnologias que podem ser
empregadas na construção de aplicações distribuídas.

2.2 SURGIMENTO

O cientista da computação Trygve Mikkjel Heyerdahl Reenskaug foi o
responsável pelo Model-View-Editor que foi o primeiro nome dado ao padrão arquitetural de
projeto criado em meados da década de 70. O norueguês, que nesta época estava como um
cientista visitante na empresa Xerox Parc©, pesquisava junto ao grupo de desenvolvimento do
projeto Smalltalk (tal projeto tratava-se de uma das primeiras linguagens puramente orientada
a objeto).
Transpondo os sistemas que existiam em sua época e focando um estudo nas
GUI’s (Graphical User Interface), Reenskaug criou a primeira implementação para o MVC
que surgiu como uma forma otimizada de se construir tais interfaces gráficas com o usuário e,
segundo o próprio Reenskaug, a concepção do nome foi uma das partes mais duras, pois era
extremamente difícil encontrar um bom nome para a diferente arquitetura de componentes
que tratara.

26

Após longas conversas, principalmente com Adele Goldberg, o termo Model-
View-Controller foi aderido de vez, deixando a palavra Editor de lado.
Antes mesmo de imaginar o MVC, Trygve estudava formas de implementar
sua estratégia de que o sistema a ser construído deveria ser decomposto em componentes, de
forma que o sistema resultante fosse suficientemente flexível podendo ser facilmente
modificado para atender à mudanças.
Segundo Gamma et al (2000) o MVC é formado, essencialmente, pela
combinação dos padrões de projeto Observer, Composite e Strategy, aproveitando-se dos
recursos de cada um para atender a seus propósitos.
Conforme citado, o MVC surgiu como uma forma melhorada para construção
de interfaces gráficas, mas tomou grande amplitude e passou a ser utilizado, de uma forma
geral, na arquitetura de sistemas complexos.
Toda a parte histórica, incluindo a documentação da época, permanece
disponível na página pessoal de Reenskaug junto a Universidade de Oslo
(http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html). Lembrando que o mesmo
dedicou-se também a pesquisa voltada a UML (Linguagem de Modelagem Unificada).

2.3 APLICAÇÃO

Muitos problemas aparecem quando o código está fortemente acoplado, o
acesso a dados, regras do negócio e apresentação estão no mesmo código. Essa ênfase é
fortemente tratada pela Sun Microsystems (2002) que salienta também, dentro de suas boas
práticas de implementação, a necessidade de aplicações empresariais terem de suportar
múltiplos tipos de usuários e diferentes tipos de interface.
O MVC que separa a lógica de negócios no model, a apresentação na view e a
interação entre eles no controller, também se apresenta como uma boa escolha para a
construção de aplicações web interativas. Isto devido ao fato de neste tipo de aplicação
haverem grandes quantidades de interações de diversos tipos de usuários e buscas e exibições
de dados.
Brown (2003), analisando especificamente a linguagem Java, ressalva o
conceito onde os componentes da view eram identificados como componentes GUI e os
controllers eram componentes que uniam esses elementos. E, ainda na visão de Brown, as

27

tendências atuais fazem o padrão ser normalmente empregado em projetos baseados na web,
onde a solução é dividida da seguinte maneira: JSP ocupam o posto de elementos de visão;
Servlets são os controladores e os Java Objects como JavaBeans assumem o papel de modelo.
A seguir (figura 1) uma imagem que ilustra essas definições:

Figura 1 – Padrão MVC aplicado para GUI e tecnologias Servlet/JSP.
Fonte: Brown, 2003, p. 58.

O MVC, portanto, demonstram que é um padrão arquitetônico que se adéqua
de forma concisa a soluções na web. Isso, graças à separação de camadas conforme a sua
funcionalidade.
A partir dessa definição e maior aprofundamento, a pesquisa trata do
desenvolvimento voltado para as aplicações web já citadas, cabendo lembrar que o
desenvolvimento para desktop também aplica de forma correta e eficaz o pattern em questão.

2.3.1 Vantagens e desvantagens

O uso deste design pattern, como de outros padrões diversos, exige um
empenho inicial no estudo, permitindo definir de forma correta, quando sua utilização
apresenta vantagens e quando a mesma pode ser de alguma forma onerosa.

28

Há projetos que são extremamente modestos e que, muitas vezes, resumem-se
em poucos formulários que se comunicam com um banco de dados através de um acesso a
dados. Para esses projetos pequenos, onde não é necessária uma lógica de negócio apurada e
muito menos a existência de diversas visões para o usuário, a aplicação do padrão pode gerar
uma visível desvantagem que é a complexidade desnecessária.
Contudo, ainda em casos pequenos deve ser levado em consideração que os
requisitos dos clientes são extremamente mutáveis e o sistema que é simples em um dado
momento, pode sofrer o acréscimo de várias funcionalidades tornando-se um grande software.
Segundo Basham, Sierra e Bates (2005) a aplicação do padrão MVC possibilita
o desacoplamento das partes do programa deixando-o modularizado. O sistema é decomposto
em componentes com funções específicas e independentes uns dos outros, aumentando assim,
a coesão dos mesmos.
Todas essas características tornam o projeto mais reutilizável devido ao fraco
acoplamento, ou seja, não há interdependências entre componentes e os mesmos podem ser
empregados com pequenas adaptações em projetos futuros. Acrescentando ainda que,
reutilizando projetos que foram baseados em padrões, é aceitável que foram abordadas as
melhores práticas de pessoas experientes que trabalharam soluções neste domínio.
No MVC, os componentes se comunicam através da definição de interfaces e
troca de mensagens. Desta forma, qualquer um dos componentes pode ser modificado ou
substituído sem interferir em nada no funcionamento dos demais, basta que o novo
componente siga a implementação das interfaces definidas. Com isso se obtém a desejada
flexibilidade que os sistemas atuais exigem.
O MVC possibilita que um mesmo dado, representado no modelo, possa ser
exibido em diferentes visões da melhor e mais conveniente forma e, sempre que necessário,
novas visões podem ser criadas sem interferir em nada no modelo. Um exemplo clássico da
relação do model com a view é demonstrado na figura a seguir:

29

Figura 2 – Exemplo de um modelo representado por diferentes views (visões).
Fonte: GAMMA et al, 2000, p. 15.

Uma situação comum em que o MVC seria uma boa solução a ser adotada e
que está exemplificada pela Sun Microsystems (2002) em Java Blue Prints: Model-View-
Controller é a de um sistema que tem que suportar diversos tipos de usuários com diversas
interfaces. Segue a ilustração:

Figura 3 – Esquema de uma aplicação que deve suportar diversos tipos de usuários e
interfaces.
Fonte: Sun Microsystems, 2002.

30

Este esquema ilustra uma aplicação onde o modelo é acessado utilizando
diversas visões que podem ser implementadas com diversas tecnologias. Outro exemplo
comum poderia ser de uma aplicação Java que possui uma versão para a web, implementada
com JEE, uma versão stand-alone implementada com JSE e ainda uma versão mobile
implementada com JME.
De acordo com as idéias de Basham, Sierra e Bates (2005) o MVC aumenta a
complexidade da aplicação pelo fato de, ao aumentar a coesão dos componentes
individualmente, muitos novos componentes são necessários na aplicação. Em contrapartida,
ele minimiza os impactos das mudanças feitas na aplicação.
A divisão em componentes pode aumentar o overhead de comunicação entre os
mesmos. Esta é uma pequena dificuldade a ser enfrentada, sendo dissolvida com uma maior
atenção na parte de análise do software, garantindo que os processos estejam otimizados e que
a modelagem condiz com a realidade necessária para atender a aplicação.
Embora ao adotar o MVC o trabalho no desenvolvimento fique maior e mais
complexo, o rendimento na produção de software pode aumentar devido à possibilidade de se
terem equipes desenvolvendo em paralelo cada parte do sistema e, também, à possibilidade de
melhor entendimento entre os membros da equipe, devido ao vocabulário comum que se
estabelece quando se adota padrões para o desenvolvimento.
O MVC é utilizável em aplicações de grande porte, onde devem ser atendidos
os atributos para um bom produto de software. Com isso, o correto é que o MVC, com sua
divisão em camadas, torna o projeto extremamente legível, sendo vantajoso para uma
aplicação futuramente manutenível.
Conforme afirma Govoni (2005) a própria implementação de swing no Java
adota este padrão, devido a sua forma de tratar as interações dos usuários com a delegação de
tratamentos destas interações.

2.4 COMPONENTES DO PADRÃO MVC

A essência do padrão MVC está no relacionamento entre os componentes
model, view e controller. Cada um possui uma responsabilidade específica para o
funcionamento do sistema, e através das interações que ocorrem entre eles obtém-se o
resultado desejado.

31

Como a separação de componentes é a característica fundamental do padrão,
cabe explicar que essa divisão, segundo Eckstein (2007), desacopla o acesso a dados da lógica
do negócio e também da maneira na qual a informação é exibida para os clientes finais. Essa
separação que torna os sistemas desenvolvidos com este padrão mais flexíveis, manuteníveis e
ainda permitindo o reuso dos componentes.
Conforme artigo da Developer Connection da Apple (2008), o MVC foi
construído a partir dos padrões Composite, Strategy e Observer, seguindo a imagem a seguir:

Figura 4 – Versão tradicional do MVC.
Fonte: Apple Developer Connection, 2008.

Neste modelo tradicional os padrões Composite, Strategy e Observer atuam
sobre as camadas as quais estão indicados, ou seja:

• Composite: Representam a view e é um composto de objetos aninhados
trabalhando de forma coordenada hierarquicamente;

• Strategy: Trabalham na camada do controller e seus objetos
implementam a estratégia para os views;

• Observer: Atuando no componente model, que mantém a lógica do
negócio da aplicação, o padrão é utilizado para enviar notificações de
alteração de estado para as views.
Esses padrões trabalham juntos no MVC tradicional e, como notado na imagem
anterior, uma mudança no modelo deve ser notificada por este componente para a visão.

32

Contudo, como se exige um alto grau de reusabilidade destes componentes, adotou-se a
utilização do controlador para ficar responsável por definir transição de mensagens de troca
no modelo para a visão, com isso um novo diagrama define melhor o contexto atual do MVC
que é voltado para web (também conhecido como MVC Model-2):

Figura 5 – Versão do MVC web (MVC Model2).
Fonte: Apple Developer Connection, 2008.

Desta nova maneira, o controlador ganha a responsabilidade de receber a
notificação do modelo e transcrever que deve ser feita uma atualização na visão. Esta
alteração torna a view menos acoplada ao model e é satisfatória para o cenário de
desenvolvimento de aplicações para web.
Para Basham, Sierra e Bates (2005): “a essência do MVC é que você pode
separar a lógica de negócio da apresentação, mas ponha algo entre elas para que a lógica de
negócio possa agir sozinha como uma classe JAVA reutilizável, sem precisar saber nada
sobre a view.”

2.4.1 Modelo (Model)

A camada do modelo é designada como o núcleo da aplicação que funciona
implementando toda a lógica do negócio e as operações que governam e modificam tais dados
(SUN MICROSYSTEMS, 2008). Com isso, o modelo é o software (todas as classes e
funcionalidades) em si. O model representa e manipula, seguindo as regras de negócio, os
dados do sistema.

33

De acordo com Reenskaug (1979), definindo o que é o model, ele representa
conhecimento, e pode ser um único ou uma estrutura de objetos. O model pode ser
considerado a aplicação em si ou, o nível mais baixo da mesma.
O modelo encapsula o estado e comportamento da aplicação além de ser o
único componente do MVC que faz interface da aplicação frente à fonte de dados, que
normalmente é representada pelo banco de dados da aplicação.
Um conceito errado e freqüente é que o banco de dados de uma aplicação é o
próprio model. Na verdade, o banco de dados constitui a camada de persistência do modelo e
os componentes model são os únicos a acessarem e executarem alterações no banco de dados.
É valido observar que a persistência também poderia ser implementada pelo uso de outros
dispositivos.
Conforme Souza (2004), devido aos bancos serem, em sua esmagadora
maioria, relacionais, é necessário no modelo existir um mapeamento dos objetos do software
orientados a objeto, para as tabelas do banco de dados. Essa técnica é o Mapeamento Objeto-
Relacional (ORM – Object Relational Mapping). Além desta técnica, há o padrão DAO (Data
Access Object – Objeto de acesso a dados) que permite melhor acesso a dados por parte dos
objetos.
Salientando a ausência de dependências entre os componentes, segundo
Basham, Sierra e Bates (2005), no MVC, a lógica de negócio (o model) não fica apenas
separada da apresentação, ela sequer sabe da existência da mesma. O model é a combinação
dos dados e dos métodos que os manipulam. Com isso, o reuso provido pelo MVC se dá
principalmente neste componente (modelo), sendo este o núcleo funcional do sistema.
Antes do MVC voltado para a web o modelo deveria também executar a tarefa
de enviar notificações das atualizações em seus dados para que as views tivessem informações
consistentes e atualizados com as últimas versões disponíveis e presentes no software.
Para promover um desacoplamento, atingindo melhor o objetivo do padrão em
si e tornando os componentes mais independentes entre si, no MVC2, o model é notificado
através do controller quando alguma view requer a exibição de dados ou provoca a alteração
dos mesmos. Em resposta, o model, disponibiliza para a view, através do controller, os dados
requisitados ou o seu novo estado após a atualização provocada.

2.4.2 Visão (View)

34

A visão é o componente da arquitetura MVC que é responsável pela
apresentação, é a interface de representação do modelo, ou seja, trata-se da fronteira entre
usuário e o sistema em si.
A definição de Reenskaug (1979) para a view diz que ela pode, da forma mais
conveniente, exibir alguns atributos e ocultar outros, atuando como um filtro para os dados do
modelo. É papel do controlador definir a view apropriada para a exibição da resposta obtida
pela requisição feita.
No modelo tradicional do MVC, décadas após a concepção de Reenskaug,
apesar de ainda com os ideais do mesmo, a view é composta por GUI’s (Graphical Users
Interface) enquanto que no MVC web a visualização das informações acontece através das
páginas HTML (HyperText Markup Language – Linguagem de Marcação de Hipertexto) para
informação estática e JSP, ASP, PHP, dentre outras, para informações dinâmicas.
Outra diferença entre o MVC original e o web é que as views no original
recebiam notificações do model, feitas por sua vez, através da implementação de interfaces
que definem objetos observadores e observados. No caso de aplicações web estas notificações
são sempre mediadas pelo controlador, principalmente pela necessidade do reuso.
Ainda assim, a visão deve ter definido um procedimento de atualização que é
ativado por um mecanismo de propagação e troca. Devido à associação direta com os
controllers, as views estabelecem com os mesmo um relacionamento ‘um-para-um’.
É na visão que ocorrem todas as interações do usuário que serão tratadas pelo
controlador para chamar os métodos apropriados no modelo.
Este componente pode ser considerado o mais flexível do MVC, podendo ser
facilmente alterado ou substituído. Novas visões também podem ser facilmente
implementadas, sem afetar em nada a estrutura do sistema.
De acordo com Sun Microsystems (2002) no artigo Java BluePrints: Model-
View-Controller , a view renderiza o conteúdo do modelo e deve manter uma consistência na
sua apresentação quando os dados do modelo mudam.

2.4.3 Controlador (Controller)

Este componente controla a comunicação entre o modelo e a visão.

35

Pode ser considerado como a fronteira entre os outros dois componentes do
MVC e sua finalidade é controlar interações que ocorram a partir do usuário (recebe o input)
que trabalha sobre elementos na camada de visão e descobre o que essa entrada significará
para o modelo. Ou, ainda, do modelo em resposta às ações anteriores.
As entradas que esses componentes recebem são, normalmente, eventos de
mouse, entradas de teclado, entre outras. Estes eventos por sua vez serão traduzidos em
requisições de serviços para outro componente que deverá tratar.
Eckstein (2007) define a responsabilidade do controller.

The controller translates the user's interactions with the view into actions that the
model will perform. In a stand-alone GUI client, user interactions could be button
clicks or menu selections, whereas in an enterprise web application, they appear as
GET and POST HTTP requests. Depending on the context, a controller may also
select a new view -- for example, a web page of results -- to present back to the user.

É o controller que define o comportamento da aplicação, mapeando as ações
do usuário em atualizações e buscas no modelo, e também selecionando qual a view deve ser
enviada como resposta.
De acordo com a Sun Microsystems (2002), existe um controlador para cada
função da aplicação, mas algumas estratégias podem ser adotadas para que se desenvolva um
controle central e se evite código duplicado.
Em aplicações web, uma solução comumente adotada para a criação deste
controle central é a implementação do padrão Front-Controller. Um objeto é criado e serve
como ponto de entrada principal para todas as requisições que vem da view, este objeto
mapeia a requisição para o tratador adequado. O Struts é um exemplo de framework que faz o
papel de Front-Controller em aplicações Java para web.

2.5 FRAMEWORKS

Os frameworks são também conhecidos como arcabouços ou quadro de
objetos. Eles são criados para fornecer funcionalidades e um objetivo maior, podendo ser
reutilizados em forma de único componente em outra aplicação. Funcionam como a estrutura
de um esqueleto que é completada para construção de um programa completo (DALMOLIN,
1997, p. 14).

36

Assim, frameworks são conjuntos de classes que fornecem recursos e a
estrutura necessária para a resolução de problemas sob um mesmo domínio. Eles estão
intimamente relacionados a padrões de projeto e pode-se dizer que são uma implementação
genérica de uma solução.
Para Basham, Sierra e Bates (2005) “O objetivo de um framework é ‘ajudar os
programadores no desenvolvimento e na manutenção de aplicações complexas’”.
Neste momento, é importante diferenciar uma biblioteca de classes de um
framework. Enquanto em uma biblioteca existem diversas classes sem definição das relações
entre elas, cabendo ao programador relacionar as classes conforme sua necessidade; em um
framework as classes que o compõe já possuem suas relações internas definidas.
A construção de um framework se dá em função da generalização de entidades
em um projeto de domínio comum. Normalmente essa generalização também pode ser feita
devido a uma necessidade particular que certo desenvolvedor observa em uma linguagem ou
em uma gama de projeto qualquer. A construção, segundo Fiorini (2001), envolve 3 etapas
que são: análise de funcionalidades comuns, definição de pontos flexíveis (hot-spots) e o
projeto do framework em si.
Silva e Price (1997) comentam que os frameworks também minimizam o
esforço no desenvolvimento, por já possuir um conceito implementado. Contudo, a utilização
do mesmo pode acarretar na criação desnecessária de alguma classe, pelo desconhecimento
completo do arcabouço em questão. Essa é uma situação bastante tangível, afinal, na
atualidade, existem distintos frameworks em diferentes linguagens. Logo, conhecer as
características de um destes arcabouços em particular, pode ser uma tarefa trabalhosa, mas
muito relevante.

Figura 6 – Aplicação desenvolvida com uso de um framework.
Fonte: Silva e Price (1997, p. 2).

37

A imagem demonstra bastante a idealização do que se trata um framework,
como pode ser observado, ele traz consigo as funcionalidades em comum desenvolvidas e, a
partir disto, são tratadas novas características para seu emprego com o domínio específico.
Um adendo é que um framework diverge de um padrão de projeto pelo padrão
ser tratado como uma idealização de solução para problemas e dificuldades em comum,
enquanto que o framework trata-se de uma implementação em si.
Fazendo uma listagem minimalista sobre frameworks que seguem o MVC,
notamos que o mesmo se aplica em diversas linguagens, por exemplo:
• Java: Struts, Spring, JSF, VRaptor;
• PHP: Zend Framework, CakePHP, Akelos;
• Python: Django;
• Ruby: Rails, Merb.
Apesar desta diversidade existente, como item de estudo serão abordados os
frameworks voltados para tecnologia Java (JEE), por ser uma linguagem amplamente usada
no mundo, além de suas vantagens como ampla comunidade de desenvolvimento, padrões
abertos, diversos fornecedores de soluções para a tecnologia, multiplataforma e tradição
incontestável.
Acrescentando que implementar o padrão MVC sem fazer uso de algum
framework pode aumentar a dificuldade de desenvolvimento, uma vez que todas as funções de
cada componente terão que ser implementadas e planejadas a partir do zero.

2.5.1 Struts

Concebido pelo programador Craig R. McClanahan, o framework foi oferecido
para a Apache Software Foundation (ASF) durante o ano de 2000 para o projeto Jakarta,
assim o Struts tornou-se Jakarta Struts Framework. Sua versão corrente é a 2.1.6, de 12 de
janeiro de 2009. Atualmente, ainda é o framework MVC mais utilizado em soluções web
MVC, embora se diga que seu uso está em declínio.
Conforme definido pela Apache (2009) o Struts é um framework livre e de
código aberto para criação de aplicações web com Java. Essas aplicações provêm interação
com banco de dados, lógica do negócio e entregam ao usuário final, o resultado de uma
resposta dinâmica.

38

O Struts atua como um Front-Controller, padrão onde, para Basham, Sierra e
Bates (2005), “todas as solicitações passam por um só controlador, o qual se encarrega de
fazer o dispatching da solicitação para os lugares apropriados”. O Struts é implementado
utilizando recursos como xml, servlets e JavaBeans e fornece diversas funcionalidades como:
tags customizadas, tratamento global de exceções, extensão via plug-ins, entre outros.
O framework provê três componentes chave que são requisições, respostas e
tag library (conjunto de bibliotecas que ajuda o desenvolvedor a criar aplicações interativas).
Hoje, o projeto conta com ampla colaboração mundial, onde uma comunidade
de desenvolvedores contribui com melhorias, correção de erros e acréscimo de
funcionalidades sem obter ganhos financeiros pelo auxílio prestado. Isso faz com que uma
vantagem deste framework seja a ampla incidência de informações e exemplos para os
programadores.
Contudo, segundo Raible (2006), o Struts apresenta também algumas
desvantagens que podem direcionar o desenvolvedor para outros frameworks, dentre elas:
ActionForms são ruins de programar; há rumores de que os projetos do framework estão
“mortos” e não é possível executar testes, exceto na integração.
Além destas considerações, para Nascimento (2005) “o JSF (Java Server
Faces) faz tudo o que o Struts se propõe a fazer e ainda oferece um poderoso modelo de
componentes”. Isso significa que, se há outro framework que cumpre com o proposto pelo
Struts, acrescentando novas características, o desuso do Struts pode aumentar com o tempo e
a tendência é que ele seja substituído em novas aplicações.

2.5.2 VRaptor

Segundo a definição em seu site oficial, o VRaptor é um controlador MVC
para web focado no desenvolvimento ágil. Por meio da inversão de controle e da injeção de
dependência, este framework diminui drasticamente o tempo gasto em ações repetitivas no
desenvolvimento, como validações, conversões e direcionamentos.
Produzido por alunos brasileiros de Ciência da Computação durante o ano de
2004 na USP (Universidade de São Paulo) o VRaptor foi criado visando produzir uma
alternativa um pouco mais simples do que o Struts que era abordado em projetos destes alunos

39

de computação no instituto de matemática e estatística da própria universidade. Com o tempo,
pessoas de todo o mundo ligaram-se ao projeto e ele vem crescendo.
Atualmente a versão deste framework é a 2.6, ele é opensource e tende a
auxiliar no desenvolvimento ágil. Além disso, para desenvolvedores do Brasil, pode tratar-se
de uma boa alternativa, pela maior parte da documentação ser em português.
A lógica de negócios é implementada em classes Java simples, sem contato
com a API (Application Programming Interface) javax.servlet, o que facilita o reuso. Prioriza
convenções ao invés de configurações, dispensando assim, uma grande estrutura de arquivos
de configuração. A view não necessita ser obrigatoriamente implementada em JSP, outras
tecnologias são suportadas. Para o modelo, possui fácil ligação com o Hibernate para
implementação da camada de persistência. Outro atrativo do VRaptor está em sua simples
curva de aprendizado.

2.5.3 Spring

O Spring foi criado por Rod Johnson e é baseado no conceito de Dependency
Injection (Injeção de Dependência) e AOP (Programação Orientada à Aspectos).
Antes de explicar o que é o framework Spring em si, cabe apenas
contextualizar os conceitos da Inversão de Controle e Injeção de Dependências. Segundo
Fowler (2005), a Inversão de controle nada mais é do que a delegação de chamada de métodos
da aplicação por um contêiner e não pela estrutura usual de programação. Assim, o framework
faz o papel de coordenar o seqüenciamento de atividades da aplicação.
Como inversão de controle era um termo muito genérico, houve discussões em
que decidiram definir um nome mais apropriado para o padrão de atividades que acontecia.
De tal modo ficou definido a injeção de dependências.
Este framework utiliza a injeção de dependências para facilitar o fraco
acoplamento da aplicação. Sendo assim, programar com o Spring torna-se algo mais
prazeroso e independente (JARDIM, 2004).
A seguir (figura 7), apresentamos um quadro que dá idéia de quão modular é o
Spring e abaixo uma pequena descrição de alguns dos módulos:

40

Figura 7 – Visão geral do framework Spring.
Fonte: Developersbook, 2008.

Como cada quadro representado tem sua função específica, conforme apurado
por Augusto (2006), segue resumo sucinto de cada módulo que compõe o framework.
• Núcleo do Spring: provê as funcionalidades fundamentais do Spring, sendo o principal
elemento o BeanFactory;
• Spring AOP (Aspects Oriented Program – Programação Orientada a Aspectos): com
este módulo é possível incorporar o gerenciamento de transações declarativas em suas
aplicações, sem depender dos componentes EJB;
• Spring ORM (Object Relational Mapping – Mapeamento Objeto-Relacional): esse
módulo provê integração com o mapeamento objeto-relacional incluindo algumas
ferramentas como Hibernate, JDO (Java Data Objects), dentre outros.
• Spring DAO (Data Access Object – Objeto de Acesso a Dados): fornece uma camada
de abstração da JDBC (reduzindo a complexidade de codificar conexões e classes para
banco de dados);
• Spring web: fornece suporte a integração com o framework Struts e outras utilidades
em geral. Segundo definição de Donald (2008) o módulo web fornece os fundamentos
para o desenvolvimento de aplicações web com Spring utilizando o comprovado
MVC. O Spring Web pode ser usado em conjunto com outros frameworks MVC,
quando não se deseja utilizar o nativo Spring MVC;

41

• Módulo de contexto do Spring: trata-se de um arquivo de configuração que inclui
serviços como JNDI (Java Naming and Directory Information), EJB (Enterprise
JavaBeans, e-mail, entre outros);
• Spring MVC: com esse módulo a aplicação pode ficar totalmente baseada no modelo
MVC, com a separação entre model, view e controller.

O Spring Web e MVC fornecem recursos ao desenvolvedor como: definição
dos controllers da aplicação; mecanismos para validação de formulários em diversos níveis;
mapeamento de requisições para os locais apropriados; criação de views em diversos
formatos, não apenas com JSPs, tratamento de exceções; envio facilitado de emails; acesso a
objetos remotos.
Ainda que bastante completo, o Spring demonstra complexidade devido ao
grande número de funções de cada módulo e o entendimento geral dos mesmos. Acrescentado
a isso, há a necessidade de configuração intensa de arquivos em XML (Linguagem de
Marcação Extensível) e requer que seja escrita uma grande quantidade de código JSP.

2.5.4 WebWork

O WebWork é um framework Java para desenvolvimento de aplicações web
que, em sua versão atual (2.2.6), visa à simplificação de código e provê robustez na
reutilização de interfaces com usuário, como formulários, internacionalização (aplicação pode
estar em vários idiomas trocando apenas arquivos de configuração), validação do lado do
servidor, características como o suporte a Ajax, e inversão de controle com o contêiner
Spring, entre outros.
Foi construído com o princípio de prover produtividade e códigos simples para
o desenvolvimento. O WebWork é similar ao Struts, ele atua como um controlador fazendo
redirecionamentos de acordo com cada requisição. Este framework possui uma grande
capacidade de abstrair a camada de apresentação, não importando quem irá criar a visão, ele
irá entregar os objetos necessários para o renderizador apropriado.

42

Indo além nesta abstração, as ações que o programador define não ficam
dependentes do ambiente web; devido ao fato de o WebWork ser baseado no XWork (que
provê um command pattern framework e também um container para inversão de controle).
Com isto, diversas tecnologias para a visão podem ser empregadas, como HTML, Swing,
PDF, XSTL, entre outras; sem que seja necessária nenhuma mudança no código escrito pelo
programador.
Algumas vantagens que podem ser citadas sobre o WebWork são arquitetura
simples e de fácil extensão e biblioteca de tags fácil de usar e customizar; como desvantagens
pode-se destacar sua fraca documentação e comunidade. Porém, como lado negativo deste
framework, a documentação ainda encontra-se organizada de forma pobre e a
comunicatividade do mesmo é baixa. (RAIBLE, 2006)

2.5.5 JSF (Java Server Faces)

O JSF é um framework opensource para desenvolvimento web que foi
incorporado à especificação do JEE. Por ser opensource, o JSF é totalmente expansível
permitindo que terceiros implementem e distribuam novos componentes para a criação de
interfaces de usuário.
De acordo com Horstmann e Geary (2005), para quem está familiarizado com
o desenvolvimento Java para desktops, o JSF pode ser pensado como um Swing para
aplicações que rodam em um servidor, inclusive com o modelo de tratamento de eventos. Para
aqueles que têm experiência com JSP, o JSF irá fornecer recursos que os desenvolvedores JSP
teriam que construir manualmente. E para aqueles que já conhecem outros frameworks para
aplicações web, como o Struts, nota-se que o JSF possui uma arquitetura similar, porém mais
flexível e expansível.
De acordo com definição da própria Sun Microsystems (2006), o JSF
estabelece o padrão no servidor para a construção de interfaces com usuário. Ainda de acordo
com a Sun, o JSF é constituído, em parte, por um conjunto de APIs para representar
componentes de interface com usuário e gerenciar estes componentes, sua movimentação,
eventos, entradas recebidas, fluxo de navegação entre páginas, tudo isto com suporte à
internacionalização e acessibilidade. E a outra parte da constituição do JSF consiste de uma
biblioteca de tags customizadas, para inserir os componentes em páginas JSP.

43

Embora seja focado na construção de componentes para interface, o JSF
implementa o padrão MVC como um todo, possuindo também um servlet controlador, o
FacesServlet, que atua como um Front-Controller, muito similar ao Struts. Para toda
requisição, o FacesServlet verifica o arquivo faces-config.xml, que define as regras de
navegação, e mapeia a requisição para o recurso necessário.
Através do uso dos chamados BackingBeans do JSF, é muito simples transferir
dados entre a visão e a camada de plano de fundo da aplicação, o modelo. Toda a lógica de
negócio da aplicação, também fica implementada em Java Beans.
Os BackingBeans, são classes Java comuns, com os devidos atributos e
métodos get e set. Novamente de acordo com Horstmann e Geary (2005), em aplicações JSF,
os beans são usados para acessar todos os dados necessários a partir de uma página. Os beans
são vias de circulação de dados entre a interface e a lógica da aplicação. Os BackingBeans
recuperam e armazenam os estados dos componentes de interface do JSF.
Através do uso de outros frameworks como, por exemplo, o Ajax4jsf, é
possível acrescentar suporte a AJAX em aplicações JSF, enriquecendo a aplicação. É possível
também desenvolver interfaces mais elaboradas através da adoção do RichFaces, uma
biblioteca de componentes para aplicações JSF.
A seguir, uma figura que ilustra resumidamente, o ciclo de vida de uma
requisição no JSF.

Figura 8 - Arquitetura JSF baseada no modelo MVC.
Fonte: Pitanga, 2004.

44

Quando uma requisição é feita, o FacesServlet, que deve ser configurado no
arquivo web.xml da aplicação no servidor, verifica no arquivo de configuração faces-
config.xml para qual recurso deve ser enviada esta requisição e a transfere. É nesta etapa,
quando houver transferência de dados, que os dados são validados e tratados de acordo com a
lógica de negócios programada para que atuem sobre o modelo. Baseada na árvore de
componentes UI do JSF, a view selecionada para exibir o retorno ao usuário, é renderizada e
enviada ao cliente.
Um exemplo simples do funcionamento do ciclo de requisição do JSF é
demonstrado em um pequeno exemplo retirado do livro Core Java Server Faces, onde um o
usuário informa seu nome de usuário e senha, e estes dados são recuperados em outra página
através dos BackingBeans do JSF.

1 - <html>
2 - <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
3 - <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
4 - <f:view>
5 - <head>
6 - <title>A Simple JavaServer Faces Application</title>
7 - </head>
8 - <body>
9 - <h:form>
10 - <h3>Please enter your name and password.</h3>
11 - <table>
12 - <tr>
13 - <td>Name:</td>
14 - <td>
15 - <h:inputText value="#{user.name}"/>
16 - </td>
17 - </tr>
18 - <tr>
19 - <td>Password:</td>
20 - <td>
21 - <h:inputSecret value="#{user.password}"/>
22 - </td>
23 - </tr>
24 - </table>
25 - <p>
26 - <h:commandButton value="Login" action="login"/>
27 - </p>
28 - </h:form>
29 - </body>
30 - </f:view>
31 - </html>

Nas linhas 2 e 3 são feitas as importações das bibliotecas de tags customizadas
do JSF, é através delas que todos os componentes serão inseridos na view. Todas as tags do

45

JSF devem estar contidas dentro da tag <f:view> que se inicia na linha 4 e termina na linha
30. Na linha 9 é iniciado um elemento <h:form> que quando renderizado, irá gerar um
elemento html <form>.
Os elementos <h:inputText> e <h:inputSecret>, nas linhas 15 e 21
respectivamente, correspondem a elementos input do html do tipo text e password. Um
diferencial do JSF é que estes elementos são automaticamente vinculados a um BackingBean
através do delimitador #{...}. Tomando como exemplo a linha 15, este inputText, está
vinculado ao atributo name do objeto user. Quando o formulário é submetido, o método
setName() do objeto user é chamado, passando como parâmetro, o valor que está inserido no
input. Quando o elemento é renderizado, o método getName() é chamado para preencher o
campo do formulário com o valor armazenado no atributo do objeto.
O elemento <h:commandButton>, na linha 26, é similar a um botão do tipo
submit do html, o diferencial é que seu atributo action pode conter tanto uma string simples,
que será usada para direcionar a navegação de acordo com o mapeamento feito no arquivo
faces-config.xml, ou a chamada para um método em um BackingBean.
A implementação de um BackingBean consiste em uma classe Java simples
(POJO), com os devidos atributos e métodos get e set, que serão chamados no momento da
submissão ou renderização de um form, conforme citado. Segue uma demonstração.

1 - public class UserBean {
2 -
3 - private String name;
3 - private String password;
4 -
5 - public String getName() { return name; }
6 - public void setName(String newValue) { name = newValue; }
7 -
8 - public String getPassword() { return password; }
9 - public void setPassword(String newValue) { password = newValue; }
10 - }

Os BackingBeans utilizados na aplicação e o mapeamento de navegação devem
ser feitos no arquivo de configuração faces-config.xml.

1 - <?xml version='1.0' encoding='UTF-8'?>
2 - <!DOCTYPE faces-config PUBLIC
3 - "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"

46

4 - "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
5 -
6 - 
7 - <navigation-rule>
8 - <from-view-id>/index.jsp</from-view-id>
9 - <navigation-case>
10 - <from-outcome>login</from-outcome>
11 - <to-view-id>/welcome.jsp</to-view-id>
12 - </navigation-case>
13 - </navigation-rule>
14 –
15 - <managed-bean>
16 - <managed-bean-name>user</managed-bean-name>
17 - <managed-bean-class>UserBean</managed-bean-class>
18 - <managed-bean-scope>session</managed-bean-scope>
19 - </managed-bean>
20 - </faces-config>

Nas linhas de 7 a 13 é criada uma regra de navegação, que define que quando
uma solicitação é feita a partir do arquivo chamado index.jsp e a string informada for “login”
será feito um redirecionamento para a página welcome.jsp. Esta regra será aplicada, neste
exemplo, quando o commandButton na página index.jsp for clicado, uma vez que sua action
está definida com a string “login”.
Nas linhas de 15 a 19 é feito o mapeamento do BackingBean, utilizado nas
páginas index.jsp e welcome.jsp. Deve ser definido um nome para o objeto (linha 16), qual é a
classe que gera este objeto (linha 17), e qual é o seu escopo (linha 18), neste caso session,
para que ele esteja disponível durante todo o tempo em que o usuário se mantiver com a
aplicação aberta.
Na página welcome.jsp, apenas é exibido o valor do atributo name do objeto
user, que foi definido no envio do formulário em index.jsp.

1 - <html>
2 - <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
3 - <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
4 -
5 - <f:view>
6 - <head>
7 - <title>A Simple JavaServer Faces Application</title>
8 - </head>
9 - <body>
10 - <h:form>
11 - <h3>
12 - Welcome to JavaServer Faces,
13 - <h:outputText value="#{user.name}"/>!

47

14 - </h3>
15 - </h:form>
16 - </body>
17 - </f:view>
18 - </html>
welcome.jsp

Definido este estudo inicial sobre estes frameworks, incluindo uma maior
observação sobre o Java Server Faces (onde foi demonstrado um simples exemplo prático de
sua aplicação), é definido que o restante do projeto abordará o JSF, pois o mesmo apresenta
crescimento acelerado, grande possibilidades de expansões e tende a substituir alguns outros
frameworks (como Struts), por ser mais poderoso que os mesmos.

2.6 JEE (JAVA ENTERPRISE EDITION)

Em uma definição da própria Sun Microsystems (2009), Java EE é um
conjunto de tecnologias coordenadas que reduzem significativamente o custo e a
complexidade de desenvolvimento e manutenção de aplicações distribuídas, multicamadas e
baseada em componentes. Construída sobre a sólida base do JSE(Java Standard Edition), o
JEE adiciona capacidades para prover uma completa, estável, segura e rápida plataforma para
aplicações empresariais.
Atualmente na versão 1.5, ou simplesmente JEE 5, que de acordo com a Sun
Microsystems (2009) está focada em deixar o desenvolvimento mais fácil. Oferecendo
recursos como os EJBs, tecnologia JSF e APIs para desenvolvimento de Web Services, a
plataforma torna a codificação simples, porém, sem perder nada do poder que já possuía na
versão 1.4.
O JEE (Java Enterprise Edition), ao contrário de soluções que fazem
concorrência ao mesmo, como é o caso da Microsoft© com o .NET, não é um produto e sim
uma especificação. Isso significa que a cada versão, seus recursos e funcionalidades são
submetidos à JCP (Java Community Process) que, por sua vez, é uma comunidade empenhada
em desenvolver a tecnologia e auxiliar com novas idéias, aprovando as versões em questão.
A partir da JCP, os fornecedores dos servidores de aplicativos produzem suas
ferramentas atendendo uma determinada gama da especificação e cada desenvolvedor em

48

particular pode selecionar qual a solução se aplicará melhor dentro das suas necessidades do
domínio.
Conforme Bond et al. (2003), o JEE é um padrão dinâmico que fornece
funcionalidades diversas para criação de aplicativos disponíveis, escaláveis e seguros,
definindo quais serviços os servidores de aplicativos devem fornecer. Esses servidores,
portanto, proverão os contêineres JEE onde os componentes serão executados.

2.6.1 Arquitetura

O modelo de aplicações do JEE divide as aplicações em componentes,
contêineres e conectores.
Os componentes podem ser classificados em:
• clientes EE: aplicações Java stand-alone ou clientes web (que são
navegadores com páginas HTML (HyperText Markup Language) e
applets);
• componentes web: como servlets, JSPs (Java Server Pages), JSFs (Java
Server Faces);
• componentes de negócio: os EJBs (Enterprise JavaBeans).

Cada tipo de componente tem seu contêiner específico, sendo assim, existem:
contêiner de applet, contêiner web, contêiner EJB, contêiner de cliente de aplicativos.
Os contêineres fornecem um ambiente em tempo de execução para que os
componentes possam executar suas funções. Cada contêiner disponibiliza de maneira
padronizada a JavaSE (Java Standard Edition) e funções particulares como fornecimento de
comunicação entre componentes, descoberta de serviços, persistência, concorrência,
segurança, distribuição, entre outros.
Os contêineres ficam entre os clientes EE e os componentes do servidor de
aplicação, fornecendo serviços transparentes para ambos. Estes se dividem em contêineres
web, que tratam da execução de JSPs e Servlets, e contêineres EJB, que tratam da execução
dos EJBs.
Conforme definido pela Sun Microsystem (2009), os conectores definem APIs
(Interface de Programação de Aplicativos) que escondem a complexidade e promovem a

49

portabilidade. Facilitam a interação da plataforma JEE com outros sistemas, como base de
dados e sistemas legados.

Figura 9 – Contêiner JEE.
Fonte: SAMPAIO JÚNIOR, 200-.

Para prover um servidor de aplicativos, os fornecedores devem obedecer a uma
gama de requisitos da especificação JEE. Com isso, os servidores que passam em todos os
testes destes requisitos passam a possuir uma certificação de compatibilidade com a
especificação JEE.
Há variados fornecedores que disponibilizam servidores de aplicativos, dentre
eles:
• IBM: Fornece o Websphere que é bastante completo e dá suporte a
tecnologias como EJB (Enterprise JavaBeans), JSP (Java Server
Pages), XML (Extensible Markup Language), HTTP (HyperText
Transfer Protocol), entre outros;
• JBoss: Servidor gratuito que fornece apenas um contêiner EJB, não
incluindo assim, o contêiner web;
• iPlanet: Suporta plataforma JEE e fornece recursos para utilização de
XML, protocolos de aplicativos de comunicação móvel, CORBA, entre
outros;

Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo

Ähnlich wie Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Estudo De Aplicabilidade Do PadrãO Mvc Fernando & Leonardo