Servlets

Programação Java
#1

Pessoal é mais uma curiosidade do que uma dúvida…

Alguém já teve ou soube de alguém que teve algum problema em ter apenas um servlet controlador em toda a aplicação? existe algum tipo de limite de requisições, ou mesmo problema de instanciação, ou talvez sincronização (ressaltando que o servlet NÃO é do tipo syncronized) ou até mesmo problemas com sessão… ???

Se alguém souber de algum tipo de problema físico (e não conceitual) de se fazer isso me diga por favor!!!

Abraços a galera Javanesca!!!

SAL

#2

O JForum tem apenas um unico servlet controlador. Problema de perforance ou relacionados vc nao tera. O FrontController eh uma boa quando ele da conta de cuidar de toda a delegacao de servicos sem precisar ter conhecimentos especificos sobre algum modulo em particular.

Rafael

#3

Muitíssimo obrigado!!!

Estou criando uma estrura de desenvolvimento e através de algumas mágicas do reflection (adoro isso!!!) senti que só haveria necessidade de um único servlet por aplicação sendo esse o delegador de ações e o tratador de erros. daí a Dúvida!!!

Brigadão mesmo!!!

Abraços

#4

Eh, vc vai usar o Command tambem :slight_smile:

Rafael

#5

Sempre usei um único controlador, mas recentemente mudei um pouco meu design e utilizo um BaseServlet da onde todos os outros herdam. Estou gostando bastante pois vc pode criar várias funções protected no base e fazer o override quando necessário.

#6

E você acaba com um sistema onde exige um acoplamento monstruoso entre suas classes e a AbstractBaseGenericCaniveteSuicoServlet. :wink:

Não vou negar que também durante o dia eu faço coisas parecida, mas no final eu sempre faço um “trocar herança por composição”.

Normalmente todo o comportamento de um servlet base pode ser transformado em 1 FrontController que dá pull de todas as informações pros Commands. É a velha historia do “Tell, don´t ask”.

#7

Não concordo! Design Patterns é muito legal, mas usá-los sempre para parecer cool não é legal. Todo mundo aqui já ouviu esse pattern um milhão de vezes:

[color=red]“Favor composition over inheritence!”[/color]

Só que no meu caso eu quero usar herança porque eu quero (deu vontade!) e principalmente porque eu não vou perder absolutamente nada com isso. Meu servlet não vai precisar herdar nada depois, e se precisar aí sim eu vou usar composition.

Eu acho bonito e prático colocar minhas funções helpers (getSessionProfile, getErrorHandler, getLocale, etc.) como protected no BaseServlet e reutilizá-las livremente nos meu servlets.

Sim, criar um controlador e meter suas actions ou comandos num hash para acessá-las via pathinfo ou qualquer outra coisa é uma boa prática que muita gente usa e eu já usei durante muito tempo também.

Agora quero dar uma variada e não vejo porque eu deva achar que estou cometendo um pecado, pelo contrário, a vida tem sido bem mais prazerosa com todas as minhas funções e variáveis protected prontinhas para serem usadas nos meus servlets.

[size=18]Freedom to code !!![/size] 8)

#8

Na verdade, vocês estão discutindo coisas conceitualmente diferentes.

saoj, você está criando um conjunto de servlets, louds um conjunto de commands.

Se você utilizar Servlets, é claro que pode usar um servlet-pai. Questãod e arquitetura…

[]s

#9

Na verdade não phillip. Servlets foram desenvolvidas em volta de um padrão que é muito familiar a todos nós… Command!

Vejamos:

Esse diagrama é um pouco injusto até, colocando um nome bem familiar ao método do command, execute(), só faltaram ServletRequest e ServletResponse para ficar igual. :wink:

Ou seja, se estamos falando do uso do Command pattern, com ou sem um FrontController na mistura, vale lembrar qual é o grande problema dele.

O uso do Command Pattern leva o código OO próximo do procedural, um comando é a versão OO de um ponteiro de função.
Junta isso com herança sem polimorfismo que fica evidente a programação não OO da coisa.

Sergio, se você não quer programar OO, tudo bem, mas ai é melhor vc usar uma linguagem melhor, java é uma droga pra desenvolvimento procedural.

Não crie seu FrontController, use a implementação de alguem, frameworks caseiros são uma praga mil vezes pior que Struts. Deveriamos lançar a campanha: toda vez que um framework caseiro ganha vida, um político tem uma “boa idéia”.

Mas voltando a questão, patterns existem para nos ajudar problemas recorrentes e também para nos mostrar quando estamos prestes a fazer besteira. E quanto a querer fazer o mais facil, bom todos queremos isso, é por isso que são criados novos frameworks, plataformas e linguagens. O importante, porém, é não encurtar o caminho olhando apenas o próximo obstáculo, sem o horizonte sempre à vista.

#10

Pois é, louds, você está certo, mas a diferença entre o seu modelo e o modelo apresentado pelo Sérgio é que você tem um Controller. Você está usando um pattern a mais.

Ora, se você tem um controle e tem commands, as suas críticas ao pattern command se aplicam também ao seu modelo (um controller não te livra disso, apenas desacopla seus commands do framework web mas isso é necessário em todos os casos?).

Quanto à herança e compisação, falar simplesmente:

Não ajuda. Sempre? Quando? Quem? Onde? Por que? Que horas?

Relações de composição e herança são conceitualmente muito diferentes para serem resumidas em uma frase dessas. Alguém pode alegar N motivos para remover uma herança, mas se esta pessoa não conhece o sistema e seu domínio, corre um grande risco de falar besteira.

Eu concordo inteiramente com a questão do framework caseiro, mas sinto falta de um framework lightweight que facilite a construção de cadastros idiotas temporários. Não me mandem usar PHP :stuck_out_tongue: .

#11

Achei que herança é algo de OO. Na minha cabeça vc condenou o meu uso de herança só porque existe um design pattern que diz: “Favor Composition over Inheritence” e porque já existe o esquema do FrontController que vc descreveu na figura. Ora, mudar e experimentar outras estratégias de vez em quando é bom. Sendo pior ou melhor, no final evoluimos. :wink:

Está louco !!!??? Assim vc vai matar a criatividade das pessoas, forçando-as a utilizar sempre um padrão. Se programação fosse apenas seguir um monte de modelos pré-definidos eu já estaria fora dessa profissao a algum tempo. O legal de programação é que existe infinitas maneiras de fazer a mesma coisa. Sua criatividade é livre para explorar todas as possibilidades e escolher a sua.

Veja bem: Não estou falando que vc e os outros aqui devem seguir minha estratégia. Apenas citei o que eu ando fazendo. Não pretendo transfomar isso em boa prática ou padrão, apesar de estar me dando muito bem com ela. As pessoas são livres para experimentar ambas e escolher a que melhor lhe convém ou agrada.

"Favor composition over inheritance…
[color=red]… mas de vez em quando use também iheritance."[/color]

#12

O legal de programar é que existem infinitas maneiras de fazer errado mas poucas de fazer certo.

Bom, deixa eu abrir 1 parentese aqui. Se você está fazendo isso no teu tempo pessoal para coisas que são um hobby, eu estou errado e te devo desculpas Sergio.
Mas se você está fazendo isso profissionalmente, eu devo dizer que é uma atitude condenavel usar frameworks caseiros para problemas já resolvidos.

Falo por interesse proprio, frameworks caseiros fazem eu ganhar menos e diminuem as chances de conseguir um emprego melhor! Como assim?

Soluções caseiras são receitas certeiras para custos de manutenção astronômicos, altas taxas de defeito, clientes insatisfeitos, projetos fracassados, dinheiro indo ralo abaixo, demissões, menos empregos, maior oferta de mão de obra e, ufa, menores salarios sendo pagos.

O Brasil é um dos paises que menos tira proveito de TI no mundo e pelos exatos motivos citados acima.

Mas voltando ao assunto.

O concelho, não é um padrão per se, de usar composição no lugar de herança vem do fato que a segunda gera um acoplamento desnecessario.

Via de regra, herança sem comportamento polimórfico é sinal de coisa errada, assim como sobrescrever todos métodos (salvos casos como proxy ou decorator).

Eu falei em usar um FrontController, Phillip, por que ele ajuda a separar comportamento relativo a como servir uma requisição (encoding, locale, etc) do negocio envolvido no processamento dela. Esse desacoplamento não é sempre necessario. O ruim é criar uma classe base com 1 tonelada de métodos ‘helpers’ que não são sobrescritos.

Herança deve ser evitada quando temos o caso de um objeto querer usar outro, e por conveniencia apenas herdamos.

Composição e herança apenas são diferentes quando existe polimorfismo na segunda. Caso contrario é apenas uma variação sintática.

Se bem que eu adoraria um contra-exemplo, no qual é feita herança sem mudança de comportamento e possui uma boa justificativa.

Phillip, se você quer alguma coisa facil para fazer alguma algo quick’n dirty, use JSF, JSP&scripts, asp.net ou mesmo perl. Ferramentas muito mais apropriadas que servlets.

#13

[quote=louds]
Phillip, se você quer alguma coisa facil para fazer alguma algo quick’n dirty, use JSF, JSP&scripts, asp.net ou mesmo perl. Ferramentas muito mais apropriadas que servlets.[/quote]

Isso já é heavywieght demais… e ASP.net nesse contexto == php :stuck_out_tongue:

#14

Vc tem razão no que vc falou. Só acho que não devemos ser tão preconceituosos assim com a herança. Por via de regra, composition é melhor, mas herança não é uma merda.

A sua alternativa é colocar as funções helpers no FrontController e passar uma referecia do FrontController para dentro dos Actions ou Commands, certo? Daí vc acessa via composition e não via herança.

Tudo bem! Funciona também e é bonito. É inclusive uma boa prática que está há anos no mercado.

Quando estamos falando de entidades do nosso modelo de negócios, usar herança quando podemos usar composition é realmente uma má idéia. Mas como aqui estamos falando do CONTROLLER e não do MODEL, acho que o meu risco (e o do cliente) de se arrepender depois é muito baixo. Controller é algo bastante burro e previsível, já o MODEL não tem limites para a flexibilidade e complexidade. Acho que tudo que vc falou se aplica muito bem para o Model, mas para o Controller não precisa ser tão conservador assim. Entretanto vou reconsiderar a minha volta ao modelo de FrontController nos meus próximos projetos. Para não incomodar os conservadores que inocentemente acreditam possuir a solução absoluta e única para todas as coisas… “Isso aqui é certo e o resto é errado e ponto final.”

#15

[quote=saoj]Vc tem razão no que vc falou. Só acho que não devemos ser tão preconceituosos assim com a herança. Por via de regra, composition é melhor, mas herança não é uma merda.
[/quote]

Não é preconceito, é não querer usar herança como um atalho sintático pra composição. Herança tem também seu papel dentro do OOSD.

Não. Eu usaria um mediator entre o FrontController e as Actions, dessa forma o código ficaria bem mais facil de testar.

[quote=saoj]
Tudo bem! Funciona também e é bonito. É inclusive uma boa prática que está há anos no mercado.

Quando estamos falando de entidades do nosso modelo de negócios, usar herança quando podemos usar composition é realmente uma má idéia. Mas como aqui estamos falando do CONTROLLER e não do MODEL, acho que o meu risco (e o do cliente) de se arrepender depois é muito baixo. Controller é algo bastante burro e previsível, já o MODEL não tem limites para a flexibilidade e complexidade. Acho que tudo que vc falou se aplica muito bem para o Model, mas para o Controller não precisa ser tão conservador assim. Entretanto vou reconsiderar a minha volta ao modelo de FrontController nos meus próximos projetos. Para não incomodar os conservadores que inocentemente acreditam possuir a solução absoluta e única para todas as coisas… “Isso aqui é certo e o resto é errado e ponto final.” [/quote]

Para mim software é software, boas práticas não são segmentadas segundo o MVC. E essa de conservador foi, hmm, criativa!

#16

SAL, o único perigo de usar um servlet só é acabar serializando a execução de todas requisições. Já fiz isso e o problema só apareceu em produção quando o volume de requisições simultaneas se tornou elevado. Então todo cuidado é pouco quando usar blocos sincronizados e um servlet só.

#17

:stuck_out_tongue: Só achei que vc foi um pouco conservador e condenou a minha solução de bate-pronto, atitude por sinal comum da sua parte, principalmente em relação a minha pessoa.

A solução do FrontController é mais correta que a do BaseServlet. Não tenho dúvida disso. Mas acho que não há argumentos sólidos (veja bem, estou falando de argumentos concretos e não um monte de palavras bonitas) para caracterízá-la como errada ou deplorável. Ela só é menos certa e menos conservadora.

Conservador = Aplicar sempre as mesmas soluções ao pé da letra, independente da situação. Ficar achando que por isso obterá sucesso e nunca terá problemas.

Não-conservador = Quebrar de vez em quando as regras. Acreditar que mudando paradigmas se evolui de uma maneira ou de outra. Entender que para um problema há N soluções e achar que a sua é a única certa e a dos outros é muito errada é no mínimo, hummm, criativo! :stuck_out_tongue:

#18