Patterns

Oracle ADF (Application Development Framework)

Caro skill_ufmt,
Leia as várias edições das revistas Mundo Java e Java Magazine onde vc. vai achar uma ótima fonte de estudos e discussão.
vide abaixo…:

http://www.patterndepot.com/put/8/JavaPatterns.htm
http://www.theserverside.com/

                      :)  :)  :)

Olá

Que tal CGI com assembler? :lol:

Desculpe a brincadeira, mas como vê hoje em dia ninguém mais concebe uma empresa ficar inventando a roda e depois quando contrata um funcionário novo precisar treina-lo em suas tecnologias internas proprietárias. A menos que seja uma empresa muito grande que já tenha seu próprio framework, o normal é adotar um que seja fácil de usar e de contratar gente que o conheça.

Neste instante estou analisando uma ferramenta deste tipo (sitemesh)

[]s
Luca

Resumo da ópera:
:arrow: construir aplicações e não fazer uso de frameworks horizontais (que são aqueles que fornecem uma infra-estrutura básica para a construção de certos tipos de aplicativos), atualmente, é dar um tiro de 12 no seu pé. Como o thigol já comentou, você vai perder muito tempo desenvolvendo algo que já existe, está estável há muito tempo e pronto para se usar (e, em vários casos, com o código-fonte disponível para que você crie seus próprios patches e adaptações, quando necessário). O ideal é a sua empresa criar frameworks verticais (voltados especificamente para atender a construção de aplicações de uma determinada área de negócio) baseados nestes frameworks horizontais.
:arrow: usar APENAS JSP, Servlets e JSTL pode ser muito improdutivo, dependendo do tamanho e complexidade do seu projeto. Mais uma vez, frameworks horizontais estão por aí para facilitar a sua vida e abstrair de você muito trabalho repetitivo. E daí as mensagens revoltadas do Luca e do Carlos (todas elas com razão).
:arrow: Se o seu tomador de decisão tiver escolhido traçar este caminho porque ele gostaria de ter total controle sobre o que está embutido dentro de sua aplicação, comente que os frameworks open-source (como Webwork, Spring, Hibernate, Velocity…) fornecem seus fontes para fazer deles o que a sua empresa bem quiser. E, caso queira dar uma cutucada a mais, faça-o se lembrar de que os drivers JDBC que sua aplicação provavelmente vai usar foram desenvolvidos por terceiros e que, muitas vezes, você nem tem acesso aos fontes destes drivers :wink:

Basicamente é isso. :slight_smile:

Olá Guj’s!

Achei muito interessante a resposta de todos, criticando o fato de não usar um FrameWork dentro de um ambiente corporativo!
Mas agora vocês colocaram uma pulga atrás da minha orelha!!!

No Projeto de Final de Curso na Faculdade optamos por desenvolver a camada de controle e apresentação utilizando patterns… e não usarmos de jeito maneira qualquer framework mvc.

Sinceramente eu até gostaria de usar um Framework para aprender… no caso meu interesse é por Struts…
Mas como neste caso se trata de aprendizagem e não produtividade, o que seria melhor? Usar um FrameWork ou desenvolver na unha???

Outro detalhe importante é que eu tenho interesse em desenvolver sem framework para que seja possível estudar para a prova SCWCD, colocando em prática todo o conteúdo aprendido dentro do projeto.

Qual é a opinião dos menbros do grupo? É melhor aprender Struts ou desenvolver na unha e colocar em prática o conteúdo pra prova SCWCD???

Um Abraço a Todos!
Thiago Senna

Olá

Se seu objetivo é aprender, então é realmente melhor não usar nada. Estude design patterns, entenda o patterns Front Controller e escreva uma pequena aplicação só com servlets que use o conceito de front controller e aonde o servlet seja APENAS e TÃO SOMENTE um intermediário. Atenção que o Struts viola um pouco este conceito e fica passando objetos request e response para fora do front controller.

Passado a fase de aprendizado, se amanhã vc for fazer uma aplicação profissional, então use um framework pq vc não vai trabalhar sozinho e os demais integrantes da equipe provavelmente já conhecem o framework. Escolha de preferência um framework atual fácil de entender e de usar (o que não é o caso do antigo Struts).

[]s
Luca

respondendo a todos…

por isso que gosto do GUJ os caras aqui são muito revoltz hehehe

seguindo:

Por que não framework?
O cliente quem decidiu por ser assim, isso a 2 anos atras eles montaram padrões que deveriam ser seguidos para todos os sistemas e partir de então os sistmeas saem assim, somente servlets, patterns, o cliene é a SEFAZ-MT ou seja, governo, agente até tem discutir atualizações nesses padrões que os caras tem, mas no governo é dificultoso mudar algo.

Tudo lá é sobre o Oracle, e como eles tem alguamas classes definas,(controle de usuarios, busca de servidores no estado) então eles acham que o padrão deve ser o mesmo de quando isso foi feito.

Ja trabalhei com Struts, hibernate em outros projetos que não fosse para a SEFAZ, mas pra lá todos saem sem framework, oque já deus vários problemas pra gente aqui, principalmente com produtividade e prazos :slight_smile:

Mas enfim, a questão é, como montariam algo assim, MVC, sem frameworks? quais padrões seriam interessantes? a arquitetura?

postei isso aqui pois sabia que ia virar bomba no GUJ kkkk pq depois das focas, qualquer coisa aqui mata um animal heehhe

entendo um pouco de patterns e gostaria que a discussão fosse pra este lado de melhores práticas sem framework de tercieros…

ok? mais questionamentos?

Se eh pra aprender, fazer algumas coisas na unha faz o maior sentido. Eh a mesma ideia por tras de usar notepad ao inves de uma IDE bombada quando vc esta aprendendo a sintaxe: voce vai ter que aprender algumas coisas na marra, e depois pode esquecer delas, pq viram enchecao de saco no dia-a-dia.

No mais, quando o objetivo eh produtividade, e em especial qualidade, todos os outros argumentos discutidos aqui se aplicam :wink:

Ok, dada as circunstâncias acho que você vai ter que criar as coisas na unha mesmo (hmmmm, ou não*!). Desta forma, os patterns que você deve dar uma olhada estão aqui: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

Olhando o diagrama de cima para baixo, olhe todos os diagramas até o Business Delegate.

*- que tal pegar o código do, digamos, Webwork, e criar um “forkzinho” para o povo da SEFAZ? :wink: É só uma idéia, afinal, o Webwork, em última instância, é baseado em servlets :wink:

[quote=Luca]
Atenção que o Struts viola um pouco este conceito e fica passando objetos request e response para fora do front controller.

[]s
Luca[/quote]

Luca, o primeiro e, até agora, único framework MVC que aprendi foi o Struts. Confesso que achei sensacional, talvez por ter saído da chatice de usar apenas jsps, beans e servlets, apenas. Na época eu achei uma revolução! Mas pode ser que a causa de minha exitação não tenha sido o Struts, mas sim o MVC.
Eu disse ‘confesso’ porque vejo que a maioria aqui no Guj desencoraja o uso do Struts - coitada das focas.
Contudo, eu gostaria de entender em profundidade as suas desvantagens e uma coisa que me chamou BASTANTE a atenção foi seu comentário sobre passar objetos request e response para fora do front controller.
Você poderia explicar exatamente o que esse front controller, os prejuízos caso isse problema aconteça, quando isso acontece e se é possível evitar?

Olá

Objetos response e request trazem dentro de si um monte de coisas que na verdade não tem nada a ver com o negócio. Talvez por passar requests e responses adiante, programador Struts mediano acaba misturando front controller com lógica da aplicação. Esta é um dos problemas do Struts. Outro problema é a dificuldade de entender. Há gente que programa Struts há séculos e que não sabe direito o que é da view e o que é do model.

Não sou contra o Struts. Ele tem seu valor. Mas hoje em dia existe coisa melhor e mais atual.

Meu conselho a todos: estudem Struts pois o mercado pede e há um grande legado já feito sobre ele. Porém evangelizem seus chefes para pular fora desta encrenca sempre que iniciar algo novo.

[]s
Luca

Por curiosidade, como é feita no Webwork a captura do request e response?

O webwork apenas popula os atributos da ação com os parametros da request. Isso faz com que a ação fique completamente independente do tipo de cliente dela.
Claro que é possível pegar os objetos request e response em caso de necessidade absoluta.

Mas ele faz muito mais coisas do que isso :smiley:

Desculpem-me por esta pergunta idiota!

Pelo que vocês escreveram até aqui notei que o Struts não é o Framework que cai na preferência da maiorias dos programadores do GUJ?
Eu me lembro que li alguma coisa em alguns livros de patterns e MVC que não é bom passar requests e responses por parâmetro para fora do Front Controller…
Mas afinal, qual é o Framework indicado? É o webwork, JBanana, Spring?

Se vocês puderem me passar esta informação, eu agradeço, assim posso dar uma olhada no assunto e começar a espalhar sobre os pontos fracos do struts e pontos fortes do framework indicado por vocês. Tenho amigos entrando no mercado e convencido que o Struts é o Framework… Pelo menos essa é a imagem que as empresas me passam…

E o principal é que posso também olhar o código fonte de uma ferramenta melhor que a do struts para tirar dúvidas referentes ao meu projeto de final de curso!

Um Abraço!

Pergunta idiota eh aquela que nao eh feita :wink:

[quote=Thiago Senna]Pelo que vocês escreveram até aqui notei que o Struts não é o Framework que cai na preferência da maiorias dos programadores do GUJ?
Eu me lembro que li alguma coisa em alguns livros de patterns e MVC que não é bom passar requests e responses por parâmetro para fora do Front Controller…
Mas afinal, qual é o Framework indicado? É o webwork, JBanana, Spring?[/quote]

O problema de acoplar Requests e Responses com codigo fora do front controller eh que voce torna o seu sistema dependente do servlet container, que eh um saco quando vc precisa, por exemplo, fazer um teste unitario ou um “public static void main()” da vida so pra saber se alguma coisa ta certa sem ter que fazer war, deploy, reiniciar container, esperar mais um pouco e depois testar usando o browser.

O Struts eh o unico framework que te forca a ter esse problema, pq HttpServletRequest e HttpServletResponse estao nas assinaturas dos metodos das Actions, e nao tem muito como fugir. O WebWork, alem de nao ter esse problema, ainda faz muita coisa bacana, e tem uma configuracao simples. O Spring, alem de poder ser integrado com o WebWork, tem um caminhao de outras ferramentas bem poderosas e faceis de usar. A decisao de qual framework eh o melhor ainda fica dependente do tipo de projeto, claro, entao eu nao vou dar minha cara a tapa aqui e dizer que WebWork eh a unica coisa boa no mundo dos frameworks MVC, e que so ele deveria ser usado, o que, pensando bem, nao eh taaaaaao longe de ser verdade assim. Mas eu nao vou dar minha cara a tapa :wink:

O Struts tem muito suporte comercial, e isso nao deve ser subestimado. Voce nao precisa sair por ai dando uma de missionario, tambem. Faca a sua parte bem, eh soh isso que interessa no fim das contas :slight_smile:

É bom lembrar que ele só passa o request e o response para a view, coisa perfeitamente normal se o cliente é web. Você até pode passar os mesmos para o Model, mas aí o problema é de quem escreveu o código, não do Struts.
E se você não quiser ficar mexendo com request, response na View é perfeitamente possível, basta acessar tudo via forms.

Olá

Não é meu caso mas sei de muita gente que confunde se a classe Action faz parte do Model ou do Controller. E porque tanta gente fica nesta dúvida? Na minha opinião, porque o Struts é confuso assim mesmo.

[]s
Luca

No meu entendimento, no caso do Struts, - que me parece que é o correto - seria:
Model -> forms
view -> jsp
controler -> classes actions

Bem,
o que chamam aqui no fórum sobre o que seria o front-controller, creio que seria o controler, ou seja, as classes action.

As classes actions possuem um método chamado ‘execute’ que tem como parâmetros de entrada(ActionMapping mapping, ActionForm forms,
HttpServletRequest request, HttpServletResponse response)
A pergunta que me faço é se o problema de se passar o request e o response para fora do front-controller seria a chamada de um outro método qualquer, de dentro do método “execute”, passando como parâmetro, novamente, o request ou o response.

:?: Seria essa então a saída “problemática” dos RRs para fora do front-controller?

:?: Se este é o problema, gostaria da opinião dos meus Camaradas do Java explicando(pode ser mais ou menos mesmo) porque isto é considerado um problema?

Não me considero um programador ‘senior’, por isso se alguém puder dar uma :idea: aqui eu fico muito agradcido.

Por favor, podem ignorem meu último post.
:oops:
Vi depois que o post mais acima do Thiago já responde estas perguntas.
:smiley: