Iniciando um projeto WEB!

Front-end
#1

Pessoal,

Estou iniciando no desenvolvimento web e estou querendo usar apenas JSP e Servlet(como já me indicaram aqui no forum) , tenho uma aplicação utilizando fachada que segue essa estrutura.

Camada de Dados -> Camada de Negócio -> Camada Fachada

Onde minha fachada possui todos os metodos que eu preciso, a pergunta é que quando eu usava este sistema em desktop(swing) eu capturava os campos com campo.getText() por exemplo.

Eu poderia fazer isso com uma aplicação WEB utilizando JSP?

Como eu poderia proceder nessa situação? :?

#2

[quote=jmedeiros]Pessoal,

Estou iniciando no desenvolvimento web e estou querendo usar apenas JSP e Servlet(como já me indicaram aqui no forum) , tenho uma aplicação utilizando fachada que segue essa estrutura.

Camada de Dados -> Camada de Negócio -> Camada Fachada

Onde minha fachada possui todos os metodos que eu preciso, a pergunta é que quando eu usava este sistema em desktop(swing) eu capturava os campos com campo.getText() por exemplo.

Eu poderia fazer isso com uma aplicação WEB utilizando JSP?

Como eu poderia proceder nessa situação? :? [/quote]

Muda só um pouquinho para:

<%=request.getParameter(“nomeDoParametro”)%> Na view ou servlet

e para setar algo:

<%=request.setParameter(“valorQueQuerPassar”,“nomeDoParametro”)%> Na view ou servlet

#3

Mas então eu teria que transforma minha fachada em uma servlet? pra receber os parametros. :?:

#4

[quote=jmedeiros]Mas então eu teria que transforma minha fachada em uma servlet? pra receber os parametros. :?:
[/quote]

Acredito que sua fachada seja o pattern Facade, certo?

Em sendo, você está com varios métodos nela ou apenas chamando ou método operações a banco de dados, ou qualquer itpo de método, certo?

Em suma, estes métodos retornam um objeto ou uma lista de objetos, certo?

Se tu ta fazendo algo para web, ta usando sevlet, ou não?

Se tu está usando servlet, você simplesmente pode importar usa fachadada, chamar seus métodos da sua fachada, pegar o resultado do método e atribuir ele a variáveis que você usará no JSP.

Exemplo:

//Este método retorna uma pessoa com nome e idade
Pessoa novaPessoa = buscarPessoa();
//pega o nome da pessoa que sua fachada retornou e seta em uma váriavel para utilizar na view
resquest.setParameter("novaPessoa.getNome()", "nomePessoaNaJsp");
//pega a idade da pessoa que sua fachada retornou e seta em uma váriavel para utilizar na view
resquest.setParameter("novaPessoa.getIdade()", "idadePessoaNaJsp");

Lá ná JSP:

Voce pode pegar essas variáveis:
.
resquest.getParameter("nomePessoaNaJsp");
resquest.getParameter("idadePessoaNaJsp");

E o processo inverso é o mesmo princípio, só que não precisa setar nada na JSP, o “request” pega os valores que estão nos seus “imput” do form do seu html.

Digamos que você tenha:

<INPUT name=“nomePessoa”
value=“José”>

no seu servlet você deverá buscar o nome do input:

resquest.getParameter(“nomePessoa”);

O exemplo é bem banal, mas espero que te ajude de alguma forma, no mais estamos por aqui :wink:

#5

Medeiros… posso colocar uma pulga atrás da sua orelha???

Dependendo do seu projeto, é melhor você usar uma estratégio Command and Controller!!!

Façade é ideal para aplicações distribuiídas, mas para rodar no mesma jvm é só adição de complexidade.

Digo isso por que comecei meu projeto usando façade… e mudei para a estratégia Command and Controller…!!!

Abraços!

#6

jmedeiros, usando estas duas tecnologias sempre há uma forte dependência entre a página html/jsp e o servet. As sugestões do skill_ufmt são ótimas para este começo.

Mais para frente vale a pena procurar pelos tópicos indicados pelo Thiago.

#7

Valeu galera pelas dicas!

Realmente esclareceu muitas dúvidas! mas ainda tenho que estudar muita coisa!

Valeu mesmo!

#8

setParameter?

#9

Bom,

Pelo que entendi ele necessitava do básico de imediato, não quis lhe passar mais informações para não confundi-lo.

É claro que FrontController, Filter e bla´bla, JSTL, são necessários, mas com o tempo ele vai descobrindo isso.

Thiago, não entendi o porque de não usar Facade? qual a complexidade?
Se não esta usando Facade, como esta isolando seus DAOs, por exemplo do resto dos servlets?

Uso Facade perfeitamente neste modelo e acho que agrega muito valor, consigo isolar completamente minha aplicação dos métodos de banco, usando intermediários como Entyte, Helper e uma Factory de DAOs.

#10

[quote=Guilherme Silveira][quote=skill_ufmt]

<%=request.getParameter(“nomeDoParametro”)%> Na view ou servlet

e para setar algo:

<%=request.setParameter(“valorQueQuerPassar”,“nomeDoParametro”)%> Na view ou servlet

[/quote]

setParameter?[/quote]

ops :slight_smile:

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?

#11

[quote=skill_ufmt]
ops :slight_smile:

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?[/quote]

Foi so para brincar mesmo. Erro comum quando a gente faz de cabeca. Quantas vezes ja nao fiquei quebrando a cabeca:

Pq esse setParameter nao esta funcionando? Eu SEMPRE fiz ele assim :slight_smile: Ai depois d emeia hora percebe que escreveu parameter :slight_smile:

Abraco

Guilherme

#12

[quote=Guilherme Silveira][quote=skill_ufmt]
ops :slight_smile:

ctrl + c ctrl + v

é foda ; )

request.setAttribute(“valorQueQuerPassar”,“nomeDoParametro”);

certo Silveira?[/quote]

Foi so para brincar mesmo. Erro comum quando a gente faz de cabeca. Quantas vezes ja nao fiquei quebrando a cabeca:

Pq esse setParameter nao esta funcionando? Eu SEMPRE fiz ele assim :slight_smile: Ai depois d emeia hora percebe que escreveu parameter :slight_smile:

Abraco

Guilherme[/quote]

e como da uma dor de cabeça hehehe

#13

E ai Skill… tudo bém???
Quanto tempo hein??

Por favor, alguém me corrija se eu estiver errado. O Façade em uma arquitetura que esteja na mesma jvm e numa aplicação web que tenha a arquitetura MVC em minha opinião aumenta um pouco a complexidade. Digo isso porque as Actions ou os Commands desempenham o papel das Fachadas… ou seja… ele iniciará uma transação, conterá a s lógicas de negócio, chamará os Daos para persistência e etc…

Então eu pergunto. O que é que um Façade faz??? Faz o que citei acima, e te tá uma objeto que contém todas as operações que o sistema pode realizar. Supondo que você tem um Action, a única coisa que o action irá fazer é chamar o façade! Isso nada mais é do que um Overload de patterns! Outro detalhe é que no caso dos commands é mais fácil integrar com um FrontController, já no façade isso é possível, mas um pouco mais difícil. Pelo menos eu acho!!!

Já numa aplicação distribuída, considerand que você colocou em um façade todas as operações que o sistema poderá realizar, então isso fará com que um outro programador que está desenvolvendo a camada cliente sinta-se mais a vontade de delegar tarefas para a camada de negócios!

Eu entendo o façade como uma maneira de você separar a camada de negócio da camada cliente (ou controle). Ele só será realmente útil em um caso onde você quer proteger sua lógica de negócio de qualquer barbeirisse dos desenvolvedores que trabalham na camada controle! Não estou criticando a arquitetura, mas sim que é possível se fazer o mesmo com menos!!!

Abraços
Thiago

#14

Simples… Será que você realmente precisa fazer esse isolamento? Será que uma fábrica de DAO já não seria suficiente???

Você tem certeza que futuramente esse isolamente que você pode fazer com façade será realmente útil?

Você acha que essa camada de persistência isolada será realmente um dia reutilizado???

Abraços!!

#15

Tempo, paro o projeot lá? : )

Bom, Facade pra mim é tudo que se possa ser fachada : )
Não somente negócios/cliente, voce pode ter negocio/banco usando facade.

A Facade é usada sempre que você precise isolar algo, ou seja, encapsular.

no teu caso, tu usa uma facade pra encapsular como o cliente vai ver seus negócios, no meu caso, somente para que os negócios não vejam os DAOs.

Só são locais diferentes, mas o mesmo prícinpio.

No teu caso eu concordo que commands é melhor, até por ser um padrão para isso, no caso SUN. e até mesmo uns filters e etc.

Considerando meu suo, pode ser que realmente minha fabrica nunca mude, mas não acredito nisso, ja ouviu a frase “os requisitos sempre mudam” pois é, ta ai o problema hehe

Se um dia eles mudarem, meus clientes/negocios não vão nem querer saber disso e nem precisaram, pois somente atualizaria minha factory :slight_smile:
E minha facade continuaria intacta, isso considerando uma atualização, não novas funcionalidades, pois ai teria que alterar também a Facade.

Não se entendi bem o que tu disse, mas disse que sua Facade tem lógicas de negócios? e por isso usa commands?

Acredito que facade nunca deve conter lógica alguma a não ser chamadas á métodos de outros, caso contrário não seria uma facade.

Abraços

PS: desanima com o proejto não que logo to efetivamente lá :wink:

#16

Quanto ao projeto… parou não cara… só tá embaçado de separar tempo para dedicar nele… mas o projeto vai pra frente sim!!!

Sim, os requisitos mudam. Para é melhor esperar eles mudarem. Caso isso aconteça, faça um refactoring e adicione os Façades. Imagine se por acaso você faz uma arquitetura super reaproveitável, e para seu asar os requisitos nunca mudam… e se mudam, mudam pequenos detalhes!!! É um esforço em vão, é isso que eu quis dizer!

Hehe… me expressei mau!!! Concordo com vocÊ… não deve ter logica de negócio…

Abraços!

#17

Este também é meu problema, pelo menso neste mês, depois vamo entrar de cabeça no projeto :wink:

Considerando que detalhes como você disse, também são mudanças e que afetam sim alguma coisa, caso contrario não seria uma melhora, certo?

Alguma vez na sua vida, por favor me diga, algum raio de requisito seu NUNCA mudou? :slight_smile:

Se não mudou meu hiper extensivos parabéns, pois tu é o cara :slight_smile:

[quote]
Hehe… me expressei mau!!! Concordo com vocÊ… não deve ter logica de negócio…

Abraços![/quote]

Aeeeeeeeee d: )

Abraços

#18

Claro que sim… é innevitável! O problema é que a gente nunca sabe onde o requisito vai mudar! O pior é que requisito vai mudar bém naquele ponto onde você não se preveniu!
Por isso é melhor você adotar refactoring do que tentar ficar prevendo mudanças!

É, então eu não sou o cara!

#19

[quote=Thiago Senna]

Claro que sim… é innevitável! O problema é que a gente nunca sabe onde o requisito vai mudar! O pior é que requisito vai mudar bém naquele ponto onde você não se preveniu!
Por isso é melhor você adotar refactoring do que tentar ficar prevendo mudanças!

É, então eu não sou o cara![/quote]

Então não preveu as mudanças direito ehehe

Eu acho que o cara bom realmente em arquitetura, analise, é aquele que consegue prever 99% do que poderá mudar.

Refactoring é massa, mas é tempo disperdiçado, é conserto, e tal, é o último caso a ser usado pelo menos para mim.

3 regras da OO:

Programe para interface.
Prefira delegação.
ENCAPSULE tudo que possa ser variável.

Se não obdecer as regras, nãos estais programando OO direito.

O que é o meu caso ehehe to longe de chegar a saber OO pura, será que o Martin Fowler, sabe? ele deve saber, ele é o cara hehehe.

Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.

Ae Shoes apresenta pra nós d: )

#20

[quote=skill_ufmt]Outro dia vi o Shoes falando que conhece 4 caras que sabem OO de verdade, eu não conheço nenhum, mas gostaria de conhecer e trocar uma idéia.
[/quote]

Acho que foi o LIPE que falou isso. :wink:

[]'s