Pergunta

Eu sou um grande fã de manter a lógica da aplicação no servlet, e mantendo o JSP tão simples quanto possível. Uma das razões para isso é que qualquer bom web designer deve ser capaz de expandir seu conhecimento de HTML para construir em algumas tags JSTL para fazer iteração simples, beans de acesso, etc. Nós também manter os mais complexos / ajax componentes / js atrás uma biblioteca de tags (semelhante ao displaytag mas para os nossos próprios componentes).

Na maioria das vezes tudo funciona ok - O servlet faz qualquer SQL ele precisa, e armazena os resultados em grãos para o JSP para acesso. Onde temos um problema é quando os registros que deseja acessar são especificados pelo design.

O exemplo mais claro seria a home page - ele precisa ser atraente e eficaz. Ele não precisa ser uniforme como resto do site. Há lotes de one-offs ou "casos especiais" aqui, onde nós queremos consultar um registro determinado produto, ou o que quer.

O que o designer realmente quer é uma maneira de obter um feijão de produto pela identificação do produto para que ele possa acessar as propriedades como normal. Nós, obviamente, não quer consulta para todos os produtos, e eu não quero consulta na apresentação.

Eu tenho certeza que eu estou pedindo o impossível aqui e que eu tenho que dar alguma coisa. A minha pergunta é o que?

Editar

Estou errado em pensar que toda a lógica de aplicação deve ser completa antes de chamar o JSP? Fiquei com a impressão de que foi considerada a melhor prática para fazer tudo consulta / cálculo / processamento no servlet, em seguida, passar (bastante) feijão mudos a um (muito) mudo JSP.

Há um par de métodos pelos quais a complexidade real da consulta pode ser encapsulado em outra classe (tag personalizado ou feijão), e o JSP pode chamá-lo. este mantém a simples JSP (meta 1), mas o JSP ainda está "provocando" a consulta - bastante no final do processo.

  • que eu tenho esta totalmente errado e não há problema em fazer isso.
  • É uma regra geral, mas perfeitamente ok para fazer isso neste caso.
  • I pode correr em problemas?

EDIT - Exemplo

Eu estou esperando que este exemplo vai ajudar:

A página inicial não é um "modelo" como a categoria páginas / search - é personalizado é projetado para funcionar muito bem com dizer uma imagem de marketing e um par de imagens específicas do produto. Ele não têm informações sobre esses dois produtos que devem ser obtidos de forma dinâmica (por isso o nome, e mais importante, preço) estadia em sincronia com o banco de dados.

O servlet não pode saber quais os produtos que estes serão, porque se o designer quer mudá-las / removê-las / adicionar mais, ele só deve ter que editar o JSP (e possivelmente XML como uma resposta sugerida).

Foi útil?

Solução

Se bem entendi, você tem lógica no JSP que quer um produto em particular, mas neste momento você não quer consulta do DB, e que seja tarde demais para o servlet para estar ciente disso.

(A nota lateral, enquanto eu respeito a sua vontade de manter a separação de interesses, o fato de que esta é uma questão mostra claramente que o quadro tem muita lógica na camada de apresentação ... mas desde que provavelmente não pode corrigir que ... seguir em frente).

A minha recomendação é que o designer cria um arquivo XML de configuração que contém tudo o que os casos especiais de que necessita para o frontend e seu servlet pode ler que, em seguida, passar feijão mudos de volta para o JSP.

ou ... você quebrar as coisas em várias solicitações usando XMLHttpRequest e chamada de volta para o servlet para cada consulta individual, em seguida, montar a página no cliente.

Outras dicas

Parece que você precisa melhor separação entre a tela eo código de banco de dados. Você deve ter classes separadas que só lidam com a interação com o banco de dados, e não sabe nada sobre tela.

Então você acabou de criar um método que irá procurar o produto por id e retornar esse feijão de modo que o display pode retirar os atributos que quer.

Você precisa criar um bean personalizado que irá executar suas consultas para o front-end. Na verdade, é provavelmente mais como um pouco de feijão para obter os dados para você, de acordo com o que você diz aqui.

Não há nenhum problema em fazer isso a partir de uma perspectiva de design; é só que o desenho específico da página inicial tem mais requisitos heterogêneos do que o resto do seu site. Verifique se o seu designer sabe que ele precisa para se comunicar suas necessidades bem para a equipe de desenvolvimento para criar o BO para sua página (ou qualquer outro) e uma coisa que deve ir bem.

Você não está errado em pensar que toda a lógica de aplicação deve ser completa antes de renderizar o JSP.

Se houver uma necessidade de buscar mais coisas para exibir em sua JSP, seria outra solicitação para o servidor e outro ciclo página. Se você está procurando a experiência de carregamento 'interativa', você poderia usar AJAX.

Em um ciclo de vida de uma única página, acho que é difícil entender por que você tem de invocar chamadas de banco de dados de uma JSP. não tem a página foi postado anteriormente, com todas as variáveis ??de formulários necessários para ajudar a encontrar os dados em classes de Servlet / Helper?

Se você pudesse dar um exemplo de um caso, seria útil.

[Edit] Olhando para o seu exemplo, sim seu criador (ou o administrador do site) deve definir essa informação como uma configuração, não uma parte do JSP. Ou, você pode ter uma página de aplicativo / admin pequena para manter as informações em um banco de dados para que ele poderia ser mudado em movimento. Quando você mostra a sua página, leia as configurações e carregar os dados apropriados.

Eu não sei o que é a questão. I f você quer ter instruções SQL fora de suas páginas JSP, então você pode colocá-los em um arquivo de propriedades e apenas ler o arquivo de propriedade da página jsp.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top