Pessoal tenho algumas dúvidas sobre essa estrutura!!!
Por exemplo, poderia usar algo assim:
View : jsp
Controler : Servlet
Persistencia : JavaBean e Banco
Regra de negócio : Classe java
Seria uma má prática ter regras de negócio dentro do JavaBean?? Ou é melhor ter um JavaBean e uma classe que trate a regra de negócio??
Espero sugestões …
[]´s
Depende… é possível fazer um modelo de eventos nos teus beans que aciona as regras de negócio automaticamente, e fica bonito, mas se vc não tiver essa paciência toda (quase ninguem tem :D), fique com a orientação a serviços, mesmo:
1: Servlet
2: Classe Java pura, tb conhecido como POJO
3: Session EJB, Stateful ou Stateless
4: Entity EJB, CMP ou BMP
5: JSP, Velocity, XSLT, ou qqer coisa do genero
cv,
Por exemplo, se eu tenho 15 telas cadastrais [jsp], será um servlet controller que administrará todas as requisições ou cada tela terá seu servlet controller?
Vi em algumas estruturas o JavaBean devolvendo a resposta para o jsp, isso é uma boa prática? Como implementar este conceito??
Preciso definir uma estrutura, mas alguns pontos ainda estão um poco confuso, se voce puder me ajudar ficarei grato!!!
[]´s
A web app “bare bones” (isto é, sem Struts, WebWork, ou outro framework MVC) mais linda que eu vi até hoje tinha apenas UM servlet, que sabia redirecionar o processamento para outros servlets, mas ele continuava sendo o ponto de entrada. Estes servlets, por sua vez, faziam o que tinham que fazer e redirecionavam para o JSP - que ficava dentro do WEB-INF 