• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

baleado

Modelação JSP

6 mensagens neste tópico

Viva pessoal estou a desenvolver uma aplicação com JSP/MySQL e à medida que vou desenvolvendo vão-me surgindo várias dúvidas de modelação.

A minha dúvida é mais uma recolha de opiniões no que toca à forma como costumam dividir o vosso código. Já vi uma aplicação em que o programador contruiu, para cada entidade da base de dados (por exemplo: utilizador, noticia, etc) duas class: entidade e GestorEntidade. Não sei porque mas tenho a sensação que isto se pode ser feito de outra forma.

Já agora aproveito a embalagem para colocar uma dúvida relativa a invocação dos beans nos ficheiro .JSP. Quando é que devemos invocar um bean usando o cabeçalho

<jsp:useBean id="objecto" class="package.class" scope="page" />

já que consegue-se aceder ao bean dentro das tags jsp (<% %>), usando simplesmente package.class.

Eu sei que isto aprende-se com a experiencia, mas sendo esta a minha 2ª aplicação em JSP não tenho muita.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sobre o uso de beans infelizmente nao te posso ajudar. Ja tentei usar essa tecnologia mas nao me entendi com isso.

Acerca da modelacao... bem... isso é uma daquelas discussoes que nao acabam.

Pessoalmente sou contra a ideia de que toda e qualquer aplicacaio que use uma base de dados deve embrulhar tudo quanto é entidade numa classe. Eu considero isso um contrasenso. Tipo, por essa ordem de ideias para que raio serve o SQL?

Na minha opiniao uma aplicacao vai muito alem de um frontend para editar a base de dados. Assim sendo nao estou a ver qual é o interesse da andar a criar classes para tabelas que só sao actualizadas em terceira instancia por exemplo.

Por 'terceira instancia' refiro-me a um tabela que é actualizada opcionalmente quando outra tabela é actualizada sendo que esta última já só é actualizada dependendo de ainda outra.

Para que criar classes para tudo e para nada... A programacao orientada a objectos é suposto simplificar as coisas e nao complicar.

Anyway... se a tua aplicacao mesmo assim for essencialmente um editor da tua base de dados... aí é capaz de compensar seguir essa estrategia de uma classe por entidade.... mas por experiencia posso dizer-te: muito dificilmente essa estrategia funciona sem umas poucas alteracoes aqui e ali... é um pouco como a propria normalizacao... é muito lindo, muito correcto e tal, mas depois para a coisa ficar bem feita na pratica e ser eficiente é sempre necessario um pouco de desnormalizacao.

Mas se optares por essa estrategia de uma classe por entidade talvez te valha a pena pesquisar sobre solucoes ORM para java. Nunca usei nenhuma, mas concerteza deve haver.

google-> java orm

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Viva pessoal estou a desenvolver uma aplicação com JSP/MySQL e à medida que vou desenvolvendo vão-me surgindo várias dúvidas de modelação.

A minha dúvida é mais uma recolha de opiniões no que toca à forma como costumam dividir o vosso código. Já vi uma aplicação em que o programador contruiu, para cada entidade da base de dados (por exemplo: utilizador, noticia, etc) duas class: entidade e GestorEntidade. Não sei porque mas tenho a sensação que isto se pode ser feito de outra forma.

Só vendo o código é que poderei confirmar mas provavelmente o que estava a ser usado era uma técnica ou tecnologia ORM, pelo que esse é o processo normal e correcto.

Já agora aproveito a embalagem para colocar uma dúvida relativa a invocação dos beans nos ficheiro .JSP. Quando é que devemos invocar um bean usando o cabeçalho

Depende do tipo de beans que estamos a falar e do objectivo da invocação, por exemplo, se estiveres a usar EJB e um Stateless Session Bean para enviar um e-mail faria mais sentido ser invocado no código do botão ou da acção que inicia o envio e não na página toda.

Mas depende também da tecnologia que estás a usar, se usares só JSP ou se usas JSF ou Structs vai influenciar a forma como os beans podem ser chamados, ou como dá mais jeito chamá-los.

Eu sei que isto aprende-se com a experiencia, mas sendo esta a minha 2ª aplicação em JSP não tenho muita.

Não sei se já leste mas seria bom leres o JEE Tutorial da Sun: http://java.sun.com/javaee/5/docs/tutorial/doc/

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Anyway... se a tua aplicacao mesmo assim for essencialmente um editor da tua base de dados... aí é capaz de compensar seguir essa estrategia de uma classe por entidade.... mas por experiencia posso dizer-te: muito dificilmente essa estrategia funciona sem umas poucas alteracoes aqui e ali... é um pouco como a propria normalizacao... é muito lindo, muito correcto e tal, mas depois para a coisa ficar bem feita na pratica e ser eficiente é sempre necessario um pouco de desnormalizacao.

Está a ver mal a estratégia a ser usada :), aliás, a estratégia que está a ser usada, se não me engano, é um padrão de acesso a dados, e como qualquer padrão é prático e criado pela experiência  e não teórico.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nao sei se a palavra "padrao" é a mais indicada para uam coisa como uma tecnologia ORM. É capaz, n sei.

Mas admitamos que seja, os padroes de software têm limitacoes praticas e a sua implementacao rigorosa é simplesmente teórica. O abuso das tecnologias ORM sao na minha opniao o melhor exemplo disto.

Tomemos o Ruby on Rails como exemplo.

Andou meio mundo ( entretanto ja acalmaram ) a dizer maravilhas daquilo... porque? Porque aquilo basicamente criava um scaffold pronto a usar na aplicacao final.

Ora quem é que tirou a maravilhosa ( not ) conclusao que uma aplicacao web serva basicamente para editar a base de dados? As minhas aplicacoes, em media usam uma base de dados para menos de 25% das suas funcionalidades.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Parece que estamos a falar de coisas diferentes :D

Um padrão não define uma implementação e não é possível fazer qualquer implementação rigoroza de uma coisa que não define a implementação. Um padrão mostra uma solução possível para um problema conhecido.

E quando falei em tecnologia ORM esta a perguntar se não estaria a ser usado Hibernate ou Toplink ou uma tecnologia conhecida.

Uma classe por entidade da base de dados é usar Entity Classes, algo que foi introduzido no JEE 5 e que permite mais facilmente resolver os problemas associados ao mapeamento de objecto com bases de dados relacionais.

A parte de abuso de tecnologias ORM é que não percebi, ORM é o que se faz quando tens de mapear objectos para bases de dados relacionais, se não usas objectos na tua aplicação então não tens qualquer ORM. Se não usares bases de dados relacionas não tens ORM :D

ORM só existe quando tens objectos e tens de os mapear para bases de dados relacionais, se não fizeres o mapeamente então não usa ORM, logo um sistema simples a usar Hibernate ou com precupações de ORM é capaz de estar mal desenhado :(

Mas com isto tudo conseguimos desviar o tópico :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora