Você está na página 1de 12

ISSN 2316-2872

T.I.S. So Carlos, v. 2, n. 3, p. 230-241, set-dez 2013


Tecnologias, Infraestrutura e Software

Arquitetura para Desenvolvimento Web


Baseado em JSF 2.0 utilizando
Padres de Projeto
Joo Paulo Ferro Gorla, Ivan Joo Foschini
Resumo: O presente artigo apresenta uma proposta de arquitetura de desenvolvimento web utilizando a linguagem Java e o framework JSF 2.0

e padres de projeto. A arquitetura est baseada em orientao a objetos, o que permite a utilizao de diversos padres de projetos que so
voltados soluo de problemas de aplicaes que seguem este paradigma. O principal objetivo dessa arquitetura fornecer uma estrutura
organizada, altamente reutilizvel e produtiva, onde o ciclo de vida da aplicao possa ser prolongado graas a fcil forma de manuteno
fornecida por esta arquitetura.

Palavras-Chave: Java, JSF, arquitetura


Web development architecture based on JSF 2.0 using design patterns
Abstract: This article proposes a web development architecture using Java and JSF 2.0 framework and design patterns. The architecture is

based on object orientation which allows the use of various design patterns focused on solving application problems that follow this paradigm.
The main goal of this architecture is to provide an organized, reusable and highly productive structure, where the life cycle of the application
may be extended through easy maintenance provided by this architecture.
Keywords: Java, JSF, architecture.

I. INTRODUO
Padres de projeto originaram-se na rea da construo
civil, onde Christopher Alexander e seus colegas propuseram
a ideia de utilizar uma linguagem padronizada para arquitetar
edifcios e cidades. O GoF (Gang of Four), composta por
quatro programadores, Erich Gamma, Richard Helm, Ralph
Johnson e John Vlissides, observaram que o conceito por trs
dos padres de projetos tambm se aplicava rea da
computao, o que resultou em um livro com as
especificaes de 23 padres de projetos para sistemas
orientados a objetos. Os padres de projetos foram
especificados para prover uma soluo reutilizvel a
problemas de software comuns a diversos projetos (GAMMA
et al., 2000).
Diante do exigente mercado de software, as empresas tm
utilizado os padres de projetos e frameworks de desenvolvimento para web com vistas a atender s necessidades desse
segmento, que cobra qualidade da aplicao e exige
resultados em prazos cada vez mais curtos. Nesse contexto, a
utilizao de padres de projetos e frameworks para o
desenvolvimento acaba sendo essencial (GAMMA et al.,
2000).
Tendo estas premissas em vista, a proposta deste trabalho
fazer um estudo sobre o padro de projeto Fachada,

especificado pelo GoF (Gang of Four), e dos padres MVC e


DAO, para expor de forma incremental a evoluo de uma
arquitetura para desenvolvimento de aplicaes web que
contenha os padres de projeto que auxiliem numa maior
estrutura organizacional. Esta arquitetura ser baseada em
frameworks disponveis para Java, como o caso do
JavaServer Faces.
O artigo esta organizado da seguinte forma: a seo II contextualiza os principais conceitos do padro arquitetural
MVC (Model-View-Controller) e dos padres de projeto
Fachada e DAO (Data Access Object) e identifica suas
caractersticas; na seo III, apresentado o JavaServer
Faces em que so descritas as principais caractersticas do
framework; a seo IV apresenta o processo de
desenvolvimento de um estudo de caso utilizando as tecnologias apresentadas; e finalmente, na seo V so
apresentados as consideraes finais, com os trabalhos
relacionados e trabalhos futuros e a concluso.
II. PADRO ARQUITETURAL MVC E PADRES DE PROJETO
F ACHADA E DAO
A seguir so descritos o padro arquitetural MVC e os
padres de projeto Fachada e DAO.

Departamento de Computao - Universidade Federal de So Carlos (UFSCar)


Caixa Postal 676 13.565-905 So Carlos SP Brasil
Autor para correspondncia: ferrogorla@gmail.com, ivan@dc.ufscar.br

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto

A. Padro arquitetural MVC

O padro arquitetural MVC (Model-View-Controller) pode


ser utilizado para representar e entender a comunicao existente entre os componentes de uma aplicao seja para web,
para desktop ou para dispositivos moveis. Os modelos de
arquitetura que utilizam o padro arquitetural MVC definem
claramente a separao de responsabilidades e a comunicao
entre os componentes de uma aplicao (TERUEL, 2012).
A camada de visualizao (View) responsvel pela interface com o usurio e controla as entradas e sadas grficas e
textuais. O modelo (Model) controla o comportamento e os
dados do domnio da aplicao respondendo as solicitaes e
instrues para mudar seu estado, alm de conter as regras de
negcio. O controle (Controller) controla as solicitaes do
usurio repassando as mesmas para o modelo ou para a
visualizao, adequadamente. Esta diviso em camadas tem o
objetivo de aumentar a flexibilidade e a reutilizao do
cdigo (GAMMA et al. 2000; BARROS et al. 2007).
Ao utilizar o padro arquitetural MVC o desenvolvedor
est mantendo seu cdigo mais organizado, tornando a
manuteno mais simples e menos custosa.
A diviso de uma aplicao utilizando o padro
arquitetural MVC pode ser visto na Figura 1.

Figura 1. Arquitetura do Padro MVC


B. Padres estruturais

De acordo com Rocha (2011), os padres estruturais definem maneiras de se compor objetos para formar estruturas
maiores e mais complexas. Ao invs de compor interfaces ou
implementaes, os padres estruturais descrevem formas de
se compor objetos para realizar novas funcionalidades. A
flexibilidade obtida fruto da possibilidade de alterar a composio em tempo de execuo.
Os padres estruturais se preocupam com a forma como as
classes e objetos so compostos para formar estruturas maiores. Os padres estruturais de classes utilizam a herana para
compor interfaces ou implementaes (SILVEIRA et al.
2012).
C. Padro Fachada

O padro Fachada apresenta uma soluo elegante na comunicao entre subsistemas, pois centraliza em um nico
ponto toda a comunicao que ocorre entre eles, reduzindo o

acoplamento e facilitando a manuteno (ROCHA, 2011).


A estrutura de um sistema em subsistemas ajuda a reduzir a
complexidade. Nesse contexto, os esforos se intensificam a
fim de minimizar a comunicao e as dependncias entre os
subsistemas. O que vem ao encontro do objetivo do padro
Fachada, tendo em vista que o mesmo define uma interface
nica e de alto nvel que torna mais fcil a utilizao de um
subsistema (ROCHA, 2011).
A motivao bsica desse padro dividir sistemas em
subsistemas para reduzir a complexidade do cdigo. O Padro
Fachada define uma interface de nvel mais fcil de ser usado,
ou seja, no daqueles tipos de interface Java em que se deve
implementar seus mtodos em uma classe concreta, e sim uma
classe comum que tem o objetivo de servir de fachada para
um subsistema. Este padro trata de associaes entre classes
e objetos, sendo geralmente utilizado em projetos orientados a
objetos (SOUZA, 2012).
Quando um sistema projetado sem utilizar o padro Fachada, o acesso do cliente s classes da base de dados realizada diretamente na classe cliente. No entanto, esta no
considerada uma boa prtica porque dificulta a manuteno e
o futuro crescimento do projeto. Tambm ocasiona o aumento
significativo do acoplamento entre as classes, o que no
desejvel quando se trabalha com orientao a objetos. O
mais indicado em um projeto ter um cliente que conhea o
mnimo possvel das demais partes do sistema.
Quando se faz uso do padro Fachada muitos benefcios
so encontrados, como:

Produzir uma interface comum e simplificada;

Poder encapsular uma ou mais interfaces mal projetadas em uma mais concisa;

Isolar os clientes dos componentes do subsistema reduzindo o nmero de objetos com os quais o cliente tem que
lidar;

Promover um acoplamento fraco entre o subsistema


e seus clientes;
O acoplamento fraco permite variar os componentes do
subsistema sem afetar os seus clientes. No h empecilho se
as aplicaes utilizarem as classes do subsistema caso seja
necessrio (SOUZA, 2012).
Como saber quando utilizar um padro de projeto e principalmente qual ou quais deles usar pode ser uma dvida presente entre a maioria dos desenvolvedores. O Fachada pode
ser utilizado quando se faz necessrio em um projeto uma
camada para um conjunto de objetos com o objetivo de
facilitar o uso da aplicao. Ou seja, quando h a necessidade
de que partes do sistema no se tornem visveis a outras partes
e assim, se evite o alto acoplamento entre elas. O uso do
Fachada viabiliza a separao do sistema em camadas com
alto grau de desacoplamento. Souza (2012) aconselha o uso
de Fachada no desenvolvimento de sistemas com persistncia
de dados (DAO) que contenha interface visual, e sempre que
for necessrio evitar que partes do sistema se misturem. O
nmero de fachadas necessrias para cada sistema no prdeterminado, use quantas forem necessrias. Muitas vezes
uma fachada pode ser usada para servir de fachada para outras
fachadas e ento, reunir em apenas um local o acesso a todas
231

T.I.S. 2013; 2 (3): 230-241

Joo Paulo Ferro Gorla, Ivan Joo Foschini

as demais (SOUZA, 2012).


D. Padro DAO(Data Access Object)

Quando em um projeto se faz uso do padro DAO porque


existe a necessidade em separar as regras de negcio das
regras de persistncia de dados. O objetivo principal
promover o isolamento entre classes de objetivos distintos
(persistncia/negcio /interface) e a flexibilidade quando se
deseja, por exemplo, utilizar diferentes SGBDs (Sistema
Gerenciador de Banco de Dados). Anteriormente, quando no
se fazia uso do padro DAO, as aplicaes eram codificadas
de forma que ficassem dependentes de um nico banco de
dados. Assim havia dificuldade de se migrar o sistema e
alterar parte do cdigo relacionado a operaes de banco e
ainda existia uma forte dependncia entre classes de negcios
com classes de persistncia. Muitas vezes as regras de acesso
a banco de dados eram programadas na prpria camada de
viso, misturando regras de exibio com regras de acesso a
banco de dados o que tornava a ampliao dos sistemas, ou
at mesmo uma simples manuteno, uma tarefa muito mais
complexa (SOUZA, 2012).
O padro DAO surge como soluo para esses problemas
de uma forma bem simples. Com ele todas as regras do
mecanismo de persistncia passam a ser mediadas por um
objeto do tipo DAO. Toda a lgica de acesso e execuo ao
banco de dados colocada dentro de um objeto DAO e desta
forma se cria um isolamento entre a API de persistncia e as
demais partes do sistema. As operaes de banco passam
ento a ser de inteira responsabilidade do objeto DAO, isolando-as do resto da aplicao.
O DAO um padro que deve ser utilizado quando se deseja encapsular o modo de acesso a base de dados. Dessa forma
passa a ser possvel utilizar fontes de dados diferentes,
tornando a obteno dos dados transparente para as classes de
negcios. Hoje em dia existe uma variedade muito grande de
bancos de dados, como Oracle, MySQL, DB2, HSQLDB, MS
SQL Server, PostgresSQL, entre outros. Essa variedade faz

com que haja algumas diferenas entre a forma de acess-los


e isso pode criar uma dependncia da aplicao em relao ao
cdigo de acesso aos dados, o que introduz um alto
acoplamento entre a lgica de negcio e a implementao do
acesso s fontes de dados. Nesse caso se torna mais difcil
migrar a aplicao de um banco de dados para outro. A
soluo encontrada pelo padro DAO abstrair e encapsular o
acesso base de dados. Com isso, a logica de negcio de um
sistema conhece apenas a interface do DAO e ela esconde
toda a complexidade das operaes de banco de dados
(SOUZA, 2012).
III. JAVAS ERVER F ACES
CONSTANZO (2012) define o JavaServer Faces (JSF) como um framework para desenvolvimento web que incorpora
caractersticas do padro arquitetural MVC e utiliza um
modelo de interfaces grficas baseado em eventos
desenvolvido atravs do JCP (Java Community Process) sob o
JSR (Java Specification Request) 314 disponibilizado pela
Sun Microsystems. A tecnologia JavaServer Faces estabelece
uma especificao para o desenvolvimento (ORACLE, 2012).
A tecnologia JSF foi desenvolvida para facilitar o desenvolvimento de aplicaes web atravs de componentes de
interface GUI (Graphical User Interface). Rene o melhor
dos universos web e desktop, sendo capaz de criar uma interface web mais rica e menos complexa de ser implementada.
Com a utilizao de duas bibliotecas de tags para a representao dos componentes UI (User Interface) que fazem a
gesto dos seus estados, do controle de eventos, da validao
dos dados, da navegao entre as pginas e tambm
automatiza o processo do uso de JavaBeans (ORACLE, 2012;
GEARY et al. 2007).
A. Caractersticas do JSF

A Figura 2 ilustra uma viso de alto nvel do framework


JSF.

Figura 2. Viso geral de alto nvel do framework JSF (GEARY et al. 2007)
T.I.S. 2013; 2 (3): 230-241

232

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto

Como pode ser observado na Figura 2, o framework JSF


responsvel pela interao com os dispositivos clientes e fornece as ferramentas para unir a apresentao visual, a lgica
da aplicao e a lgica de negcios de uma aplicao web
(GEARY et al. 2007).
Os servios mais importantes oferecidos pelo framework
JSF so (CONSTANZO, 2012):

Arquitetura MVC: adota o padro arquitetural MVC


(Mo-del-View-Controller) que divide as funcionalidades envolvidas em trs camadas, como foi explicado anteriormente.
Converso de dados: os dados digitados pelo usurio em
formulrios web so em formato texto. Porm, objetos de
negcios exigem dados em forma de nmeros, datas ou
outros tipos. O JSF facilita a tarefa de converter os dados e
customizar as regras de converso.

Validao e manipulao de erros: o framework JSF


faci-lita a tarefa de criar regras de validao a campos
obrigatrios e campos com formato especficos.
Obviamente, preciso exibir mensagens de erro apropriadas

quando o usurio digitar dados invlidos.

Internacionalizao: o JSF fornece suporte


internacionalizao, como a codificao de caracteres e
seleo de pacotes de recursos.

Componentes customizados: o JSF d liberdade para


os desenvolvedores criarem os seus prprios componentes,
bem como utilizarem outros componentes desenvolvidos por
ter-ceiros.

Renderizadores alternativos: por padro, o JSF


produz XHTML em sua sada, mas extensvel o suficiente
para produzir outros tipos de sadas como, por exemplo, WML
(Wireless Markup Language) ou XUL (XML User Interface).
B. Ciclo de Vida do JSF

A especificao JSF define seis fases distintas, conforme


ilustrao na Figura 3. O fluxo normal de controle mostrado
em linhas slidas e os fluxos alternativos em linhas pontilhadas.

Figura 3. O ciclo de vida do JavaServer Faces (GEARY et al., 2007)


MARQUES (2012) define as 6 fases do ciclo de vido do
JSF da seguinte forma.
Fase 1: Restaurar a Viso
Caso a pgina requisitada j tenha sido exibida,
recuperada toda a rvore de componentes para a pgina
requisitada. Caso esteja sendo exibida pela primeira vez
construda uma nova rvore de componentes. No caso da
pgina j ter sido exibida, todos os componentes sero
configurados com seu estado anterior.
fcil notar isso no processo de validao, onde os valores
digitados inicialmente no formulrio sero mantidos.
Se a requisio no possuir dados solicitados, a implementao JSF pula para a fase de Renderizar Resposta. Normalmente isso acontece quando a pgina requisitada pela primeira vez.
Fase 2: Aplicar Valores de Requisio

Nesta fase o JSF resgata todos os valores informados pelo


usurio e os armazena em seus objetos.
Fase 3: Processar Validaes
A cadeia de entrada com o valor enviado convertida para
o tipo correto do objeto. Caso ocorra algum erro de validao
uma mensagem de erro adicionada no FacesContext, o
componente marcado como invlido e a implementao JSF
invoca a fase de Renderizar Resposta, renderizando a viso ao
usurio levando as mensagens de erro. Caso contrrio o ciclo
de vida continua normalmente.
Fase 4: Atualizar Valores do Modelo
Sua principal atividade atribuir os valores informados pelo usurio no formulrio, para as respectivas propriedades
associadas aos ManagedBeans. Pode haver erro na converso, fazendo com que o JSF dispare um erro de tempo de
233

T.I.S. 2013; 2 (3): 230-241

Joo Paulo Ferro Gorla, Ivan Joo Foschini

execuo, caso ocorra o JSF adiciona esses erros no FacesContext e renderiza a pgina de viso ao usurio.
Fase 5: Invocar Aplicao
Nesta fase o controlador do JSF chama o mtodo associado
ao submeter o formulrio, disparando assim a camada de
regras de negcio da aplicao. Todos os valores foram
validados e carregados nas fases anteriores, por isso
poderemos us-los conforme necessitar. Geralmente
retornada uma string de resultado do mtodo para o JSF
efetuar a navegao, se esse valor for null o JSF retorna a
mesma pgina que chamou o mtodo.
Fase 6: Renderizar Resposta
Esta fase codifica a resposta e a envia de volta ao navegador.
IV. ESTUDO DE CASO: REDE S OCIAL ACADMICA - HAOBA
A rede social acadmica Haoba um software desenvolvido
para a plataforma Java EE, que tem como objetivo permitir
uma maior aproximao e iterao entre os alunos,
professores, funcionrios e visitantes dos diversos
departamentos e cursos da faculdade.
O sistema possibilita que o usurio acesse sua pgina pessoal e visualize o perfil de outros usurios, permitindo que o
mesmo possa realizar publicaes em seu mural ou no mural
de outros usurios. Possui ainda uma rea de comunidades

especificas para determinados cursos e departamentos, onde


podem ser iniciadas discusses sobre assuntos pertinentes aos
respectivos cursos e departamentos, com compartilhamento de
documentos.
Todo o sistema deve estar disponvel para acesso via web
atravs dos browsers mais conhecidos, tais como Internet
Explorer e Firefox. Eventuais funcionalidades sero acessadas
atravs de dispositivos mveis com acesso internet, como
celulares, smartphones e similares.
Esta seo apresenta o estudo de caso que descreve a aplicao do padro arquitetural MVC e dos padres de projetos
Fachada e DAO no desenvolvimento da rede social acadmica
Haoba. As classes e fragmentos de cdigo fonte utilizados nos
exemplos so originais do projeto e servem para ilustrar a
implementao e a evoluo obtida com a aplicao dos
padres de projeto.
Para exemplificar, foi selecionado o caso de uso Criar Comunidade. Este caso de uso responsvel criar comunidades
na rede social relacionadas a um determinado departamento e
curso.
A. Desenvolvimento do Haoba sem padres de projeto

A Figura 4 apresenta, resumidamente, o modelo de classes


da implementao do caso de uso Cadastrar Comunidade sem
a utilizao de padres de projeto.

Figura 4. Diagrama de Classes Caso de Uso Cadastrar Comunidade sem padres de projeto
Como pode ser observado na Figura 4, a classe Cadastrar- isto o cliente acaba sendo sobrecarregado com toda a lgica
ComunidadeMB comunicou-se com as classes de domnio do caso de uso. Tornando assim o cdigo de fonte menos
(Comunidade e UsuarioComunidade) diretamente, conforme extensvel e de difcil manuteno, conforme argumentao
trecho de cdigo apresentado no Quadro 1. Toda complexida- apresentada na seo II.
de de implementao ficou somente no managed bean, com
T.I.S. 2013; 2 (3): 230-241

234

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto
comunidade. setDataCadastro( Calendar. getInstance( ) . getTime( ) ) ;
}

comunidade. setFlgAtivo( true) ;

if( comunidade. getImagem( ) == null | | comunidade. getImagem( ) . isEmpty( ) ) {


comunidade. setImagem( " default. png" ) ;
}
if( comunidade. getIdtComunidade( ) == null) {
em. persist( comunidade) ;
}
else {
em. merge( comunidade) ;
}
UsuarioComunidadePK id = new UsuarioComunidadePK( comunidade. getIdtAcesso( ) . getIdtAcesso( ) ,
comunidade. getIdtComunidade( ) ) ;
Query query = em. createQuery( " SELECT u FROM UsuarioComunidade u WHERE u. usuarioComunidadePK. idtAcesso
= : idtAcesso AND u. usuarioComunidadePK. idtComunidade = : idtComunidade" ) ;
query. setParameter( " idtAcesso" , id. getIdtAcesso( ) ) ;
query. setParameter( " idtComunidade" , id. getIdtComunidade( ) ) ;
UsuarioComunidade usuarioComunidade = ( UsuarioComunidade) query. getSingleResult( ) ;
if( usuarioComunidade ! = null) {
UsuarioComunidade usuarioComunidade = new UsuarioComunidade( id) ;
usuarioComunidade. setData( Calendar. getInstance( ) . getTime( ) ) ;
em. persist( usuarioComunidade
}
if( comunidade. isFlgNovaImagem( ) )
FileUploadController. moveFile( new
File( " C: /vhosts/i. haoba/imagens/tmp/"
+
comunidade. getImagem( ) ) , new File( " C: /vhosts/i. haoba/imagens/comunidade/" + comunidade. getIdtComunidade( ) +
" /" + comunidade. getImagem( ) ) ) ;
}
FacesContext. getCurrentInstance( ) . getExternalContext( )
. redirect( " minhasComunidades. xhtml" ) ;

}
catch ( Exception e) {

FacesContext. getCurrentInstance( ) . addMessage( null,


new
FacesMessage( FacesMessage. SEVERITY_ERROR, " Ocorre um erro inesperado. " , " Por favor, tente novamente mais
tarde. " ) ) ;

logger. error( e. getMessage( ) , e) ;

// Getters and Setters omitidos


}

Quadro 1. Implementao sem utilizao de padres


B. Desenvolvimento do Haoba utilizando o padro Fachada

A Figura 5 apresenta, resumidamente, o modelo de classes


da implementao do caso de uso Cadastrar Comunidade

utilizando apenas o padro de projeto Fachada, promovendo


uma diviso do cdigo de visualizao da camada de negcios
da aplicao.
235

T.I.S. 2013; 2 (3): 230-241

Joo Paulo Ferro Gorla, Ivan Joo Foschini

Figura 5. Diagrama de Classes Caso de Uso Cadastrar Comunidade utilizando padro Fachada
Como foi visto na Figura 5, a classe CadastrarComunidadeMB agora passou a se comunicar com a fachada (ComunidadeFachada), deixando assim a comunicao com as classes
de domnio (Comunidade e UsuarioComunidade) sobre
responsabilidade da fachada conforme trecho de cdigo

apresentado no Quadro 3. Agora temos um cdigo mais limpo


no managed bean (Quadro 2), porm a fachada ainda continua
sobrecarregado com boa parte da lgica do caso de uso e
implementaes de banco de dados.

@ ManagedBean
@ ViewScoped
public class CadastrarComunidadeMB extends GenericoMB {
public void cadastrar( ) {
try {
comunidadeFachada. salvarOuAtualizar( comunidade) ;
FacesCon-text. getCurrentInstance( ) . getExternalContext( ) . redirect( " minhasComunidades. xhtml" ) ;
}
catch ( FachadaException e) {
FacesContext. getCurrentInstance( ) . addMessage( null, new FacesMessa-ge( FacesMessage. SEVERITY_ERROR,
" Ocorre um erro inesperado. " , " Por favor, tente nova-mente mais tarde. " ) ) ;
logger. error( e. getMessage( ) , e) ;
}
catch ( Exception e) {
FacesContext. getCurrentInstance( ) . addMessage( null, new FacesMessa-ge( FacesMessage. SEVERITY_ERROR,
" Ocorre um erro inesperado. " , " Por favor, tente nova-mente mais tarde. " ) ) ;
logger. error( e. getMessage( ) , e) ;
}
}

Quadro 2. Implementao do ManagedBean cliente com padro Fachada

T.I.S. 2013; 2 (3): 230-241

236

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto
// Imports omitidos
@ Stateless
public class ComunidadeFachada extends GenericoFachada {
public Comunidade salvarOuAtualizar( Comunidade comunidade) throws FachadaException {
try {
if( comunidade. getIdtComunidade( ) == null) {
comunidade. setDataCadastro( Calendar. getInstance( ) . getTime( ) ) ;
comunidade. setFlgAtivo( true) ;
}
if( comunidade. getImagem( ) == null | | comunidade. getImagem( ) . isEmpty( ) ) {
comunidade. setImagem( " default. png" ) ;
}
if( comunidade. getIdtComunidade( ) == null) {
em. persist( comunidade) ;
}
else {
em. merge( comunidade) ;
}
UsuarioComunidadePK id = new UsuarioComunida-dePK( comunidade. getIdtAcesso( ) . getIdtAcesso( ) ,
comunidade. getIdtComunidade( ) ) ;
Query query = em. createQuery( " SELECT u FROM UsuarioComunidade u WHERE
u. usuarioComunidadePK. idtAcesso = : idtAcesso AND u. usuarioComunidadePK. idtComunidade = : idtComunidade" ) ;
query. setParameter( " idtAcesso" , id. getIdtAcesso( ) ) ;
query. setParameter( " idtComunidade" , id. getIdtComunidade( ) ) ;
UsuarioComunidade usuarioComunidade = ( UsuarioComunidade) query. getSingleResult( ) ;
if( usuarioComunidade ! = null) {
UsuarioComunidade usuarioComunidade = new UsuarioComunidade( id) ;
usuarioComunidade. setData( Calendar. getInstance( ) . getTime( ) ) ;
em. persist( usuarioComunidade) ;
}
if( comunidade. isFlgNovaImagem( ) ) {
FileUploadController. moveFile( new File( " C: /vhosts/i. haoba/imagens/tmp/" + comunidade. getImagem( ) ) , new File( " C: /vhosts/i. haoba/imagens/comunidade/" + comunida-de. getIdtComunidade( ) +
" /" + comunidade. getImagem( ) ) ) ;
}

return comunidade;
}
catch( DAOException e) {
throw new FachadaException( e. getMessage( ) , e) ;
}
catch( Exception e) {
throw new FachadaException( e. getMessage( ) , e) ;
}

Quadro 3. Implementao do EJB ComunidadeFachada

237

T.I.S. 2013; 2 (3): 230-241

Joo Paulo Ferro Gorla, Ivan Joo Foschini

C. Desenvolvimento do Haoba com padres de projeto

O projeto utiliza o padro arquitetural MVC, o que possibilita uma diviso lgica do cdigo fonte. A camada de visualizao contm as pginas JSF que controlam os componentes
visuais da aplicao. As pginas JSF utilizam um ou mais
managed beans, tendo assim seu ciclo de vida gerenciado
pelo JSF com mostrado na seo III.
Os managed beans utilizados nas pginas JSF controlam a
aplicao, recebendo as chamadas da camada de visualizao
e executam as chamadas necessrias as classes de negcio.
Aps a execuo das regras de negcio, a camada de controle
devolve os resultados da operao para a camada de
visualizao.
A camada de servio (Fachada) responsvel por implementar as regras de negcio da aplicao. Essa camada

encapsula o cdigo de negcio da aplicao, tornando assim a


manuteno mais fcil.
A camada de persistncia (DAO) responsvel por realizar
as operaes no banco de dados. Essa camada executa a
diviso das regras de negcio, ficando exclusivamente
responsvel pela comunicao com o banco de dados,
O fluxo da aplicao tem inicio na camada de visualizao
sendo disparado por algum evento executado pelo usurio
atravs de uma pagina JSF. O managed bean controlado pelo
JSF recebe o evento, valida as entradas de dados e realiza a
chamada a camada de servios. A camada de servio pode
realizar uma ou mais chamadas camada de persistncia,
devolvendo o modelo atualizado para a camada de servio e
consequentemente a camada de visualizao.
O fluxo descrito acima pode ilustrado na Figura 6.

Figura 6. Fluxo da aplicao


A comunicao entre as camadas ocorre atravs do uso de
EJBs (Enterprise Java Beans), uma tecnologia desenvolvida
pela Sun Microsystems que possibilita o desenvolvimento
distribudo de componentes. Esse EJBs so do tipo Stateless,
T.I.S. 2013; 2 (3): 230-241

ou seja, no armazenam sesso. Aps o final de sua execuo,


o EJB finalizado. O Quadro 4 mostra o EJB
ComunidadeFachada, responsvel por todas as regras de
negcio referentes ao gerenciamento de comunidades.
238

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto
@ Stateless
public class ComunidadeFachada extends GenericoFachada {
public Comunidade salvarOuAtualizar( Comunidade comunidade) throws FachadaException {
try {
if( comunidade. getIdtComunidade( ) == null) {
comunidade. setDataCadastro( Calendar. getInstance( ) . getTime( ) ) ;
}
if( comunidade. getImagem( ) == null | | comunidade. getImagem( ) . isEmpty( ) ) {
comunidade. setImagem( " default. png" ) ;
}
comunidadeDAO. salvarOuAtualizar( comunidade) ;
UsuarioComunidadePK id = new UsuarioComunidadePK( comunidade. getIdtAcesso( ) . getIdtAcesso( ) ,
comunidade. getIdtComunidade( ) ) ;
if( ! usuarioComunidadeDAO. comunidadeJaAdicionada( id) ) {
UsuarioComunidade usuarioComunidade = new UsuarioComunidade( id) ;
usuarioComunidade. setData( Calendar. getInstance( ) . getTime( ) ) ;
usuarioComunidadeDAO. adicionarComunidade( usuarioComunidade) ;

}
if( comunidade. isFlgNovaImagem( ) ) {
FileUploadController. moveFile( new File( " C: /vhosts/i. haoba/imagens/tmp/" + comunidade. getImagem( ) ) ,
new
File( " C: /vhosts/i. haoba/imagens/comunidade/"
+
comunida-de. getIdtComunidade( )
+
" /"
+
comunidade. getImagem( ) ) ) ;
}
return comunidade;
}
catch( DAOException e) {
throw new FachadaException( e. getMessage( ) , e) ;
}
catch( Exception e) {
throw new FachadaException( e. getMessage( ) , e) ;
}
}
}

Quadro 4. Implementao do EJB ComunidadeFachada


No desenvolvimento do estudo de caso Haoba com utiliza- Object) que abstrai e encapsula o cdigo de acesso a bases de
o dos padres de projeto foram utilizadas as classes de dados do restante da lgica de negcios da aplicao. Tambm
utilizada a classe
Fachada denominada
domnio Comunidade e UsuarioComunidade, as classes da foi
ComunidadeFachada
que
fornece
uma
interface de acesso
camada
de
persistncia
ComunidadeDAO
e
implementao
da
funcionalidade,
o que reduz a
UsuarioComunidadeDAO
e
o
managed
bean
complexidade
do
acesso
do
cliente.
CadastrarComunidadeMB.
A Figura 7 apresenta, resumidamente, o modelo de classes
Para reduzir a responsabilidade da camada de modelo sobre
da
implementao do caso de uso Criar Comunidade.
a lgica de persistncia foi criada uma classe intermediria
com a utilizao do padro de projeto DAO (Data Access

Figura 7. Diagrama de Classes Caso de Uso Cadastrar Comunidade com padres de projeto.
239

T.I.S. 2013; 2 (3): 230-241

Joo Paulo Ferro Gorla, Ivan Joo Foschini

Como foi visto na Figura 7, a classe CadastrarComunidadeMB (cliente) comunicou-se somente com a classe ComunidadeFachada, conforme trecho de cdigo apresentado no
Quadro 5. Toda a complexidade da implementao foi

omitida do cliente e a classe fachada passou a reunir todas as


chamadas aos mtodos das demais classes necessrias para
executar o caso de uso.

@ ManagedBean
@ ViewScoped
public class CadastrarComunidadeMB extends GenericoMB {
public void cadastrar( ) {
try {
comunidadeFachada. salvarOuAtualizar( comunidade) ;
FacesCon-text. getCurrentInstance( ) . getExternalContext( ) . redirect( " minhasComunidades. xhtml" ) ;
}
catch ( FachadaException e) {
FacesContext. getCurrentInstance( ) . addMessage( null, new FacesMessa-ge( FacesMessage. SEVERITY_ERROR,
" Ocorre um erro inesperado. " , " Por favor, tente novamente mais tarde. " ) ) ;
logger. error( e. getMessage( ) , e) ;
}
catch ( Exception e) {
FacesContext. getCurrentInstance( ) . addMessage( null, new FacesMessa-ge( FacesMessage. SEVERITY_ERROR,
" Ocorre um erro inesperado. " , " Por favor, tente novamente mais tarde. " ) ) ;
logger. error( e. getMessage( ) , e) ;
}
}
}

Quadro 5. Implementao do ManagedBean cliente com padro Fachada


V. CONSIDERAOES F INAIS
anlise e modelagem do sistema mais trabalhosa e demorada.
O framework JSF facilita muito o desenvolvimento de apliEm seu artigo A importncia dos padres de projeto, ROCHA (2011) mostra de forma sucinta que mais importante do caes web com a utilizao de seus componentes de
que saber implementar um padro de projeto necessrio interface e suas bibliotecas de tags, e consegue reunir o
saber e entender como e qual problema determinado padro melhor dos universos web e desktop, sendo capaz de criar
pode resolver, para que sua implementao possa ser uma interface web mais rica e menos complexa.
justificada.
REFERNCIAS
SOUZA (2012) aborda em seu artigo Do DAO ao Facade
a utilizao dos padres de projetos Fachada e DAO, descre- CONSTANZO, M. A., Implementao do Padro Faade
vendo os motivos pelos quais se tornaram os padres mais
utilizando o Framework JavaServer Faces: Um Estudo de
utilizados no desenvolvimento de software, citando suas
Caso.
Disponivel
em:
vantagens e facilidades para o desenvolvimento, manuteno
<http://revistatis.dc.ufscar.br/index.php/revista/article/vie
e evoluo do sistema.
w/11>. Acessado em: 01 de Outubro de 2012.
Como possvel trabalho futuro pode-se apontar a imple- MARQUES, R., Trabalhando com componentes do
mentao de uma camada de viso para acesso atravs de
Framework JSF 2.0 e RICHFACES 4. Disponivel em:
dispositivos mveis, onde poder ser mostrado um exemplo
<http://javafree.uol.com.br/artigo/886703/Trabalhandode reutilizao das camadas Fachada e DAO, promovendo a
com-componentes-do-Framework-JSF-20-etroca da camada de viso e preservando-se todas as
RICHFACES-4.html>. Acesso em: 07 de Outubro de
funcionalidades da Fachada e do DAO.
2012.
A partir deste estudo de caso conclui-se que essencial a BARROS, T.; SILVA, M.; ESPNOLA, E., State MVC:
utilizao de padres de projeto e frameworks no desenvolviEstendendo o padro MVC para uso no desenvolvimento
mento de aplicaes orientadas a objetos.
de aplicaes para dispositivos mveis. Disponvel em:
Com a utilizao das tecnologias mencionadas no estudo de
<http://www.cesar.org.br/site/files/file/SMVC_01_0104.p
caso, foi possvel obter vantagens como escalabilidade e um
df>. Acesso em: 30 Julho 2012.
alto nvel de reusabilidade do cdigo. A arquitetura do sistema GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.,
se tornou flexvel, facilitando manutenes, de mbito
Padres de Projeto: Solues Reutilizveis de Software
corretivo ou evolutivo. Alm do mais, com a utilizao do
Orientado a Objetos. Ed. Bookman. 2000.
padro arquitetural MVC e dos padres de projeto Fachada e GEARY, D.; HORSTMANN, C., Core JavaServer Faces:
DAO, foi possvel ganhar produtividade no desenvolvimento
Fundamentos. Segunda edio. Ed. Alta Books, 2007.
de novas interfaces para o sistema, oferecidas por meio de TERUEL, E. C., Arquitetura de Sistemas para Web com Java
diferentes dispositivos.
utilizando Design Patterns e Frameworks. Ed. Cincia
Porm esse padro de arquitetura pode se tornar um pouco
Moderna. 2012.
complexo e at desnecessrio em pequenas aplicaes tendo SILVEIRA, P.; SILVEIRA, G.; LOPES, S.; MOREIRA, G.;
em vista o significativo aumento de classes a serem desenvolSTEPPAT, N.; KUNG, F., Introduo Arquitetura e
vidas para se aplicar os padres propostos, tornado assim
Design de Software: Uma Viso Sobre a Plataforma Java.
T.I.S. 2013; 2 (3): 230-241

240

Arquitetura para Desenvolvimento Web Baseado em JSF 2.0 utilizando Padres de Projeto

Ed. Elserver, 2012.


ORACLE, JavaServer Faces Technology. Disponvel em:
<http://java.sun.com/javaee/javaserverfaces>. Acesso em:
30 julho 2012.
ORACLE, Core J2EE Patterns - Data Access Object.
Disponvel
em:
<http://java.sun.com/blueprints/corej2eepatterns/Patterns/Dat

aAccessObject.html> Acesso em: 30 julho 2012.


ROCHA, A. K. S., A importncia dos padres de projeto.
Java Magazine, Ed. 96, p. 66-74, 2011.
SOUZA, M. B., Do DAO ao Facade. Java Magazine, Ed.
97, p. 60-68, 2012
LEONARDI, E., Maven, JSF 2, Spring e Hibernate. Java
Magazine, Ed. 101, p. 06-19, 2012.

241

T.I.S. 2013; 2 (3): 230-241