Oi amigo, obrigado pela sua resposta.
Na verdade, pela sua explicação, já uso o tal do BO. Só não chamo assim por não ter certeza se devo chama-lo assim, por ainda ter dúvidas básicas com relação a essas denominações e padronizações. Esta classe é a classe Usuario. O padrão DAO já uso há algum tempo. Este é mais fácil definir, IMHO, pois se faz acesso a dados, pra mim é DAO. Essa é a classe UsuarioDAO. Por ter que fazer acesso ao banco e retornar um objeto do tipo Usuario, resolvi colocar o método fazLogin() na classe DAO.
Um amigo aqui do GUJ me disse que não seria uma má prática acessar um DAO diretamente (sem passar pela classe a que ela se refere: creio ser o tal do BO). Refleti esse conceito para os servlets e passei a acessar o DAO a partir deles. Isso eliminou uma péssima prática minha (eu tinha essa sensação e o pessoal aqui confirmou esta sensação): eu usava algo do tipo usuario.getUsuario(). Dentro deste método eu populava os atributos do próprio objeto e continuava a usar esta instância. Agora meu DAO retorna o objeto necessário, como sempre fiz, mas o acesso de fora da classe Usuario e, simplesmente, faço isso que você viu, isto é, Usuario usuario = dao.getUsuario(), por exemplo.
Meu problema é o seguinte:
Tenho, simplificando, 3 tipos de cadastro: Agente, Equipamento e OS. Cada um desses 3 se desdobra em Incluir, Alterar e Excluir. Bem, para trabalhar com JSP e Servlet, de uma forma um pouco mais elegante, me vieram a cabeça essas soluções:
[list]Usar um servlet para cada operação e classe. Neste caso eu teria 3 x 3 = 9 Servlets para CRUD. Isto é, IncluiAgenteServlet, AlteraAgenteServlet, ExcluiAgenteServlet, etc. [/list]
[list]Usar um Servlet para cada classe, isto é, AgenteServlet, EquipamentoServlet e OSServlet. [/list]
[list]Usar um Servlet para cada operação, isto é, CadastraServlet, AlteraServlet e ExcluiServlet.[/list]
A primeira abordagem é fácil, só tenho minhas dúvidas se é uma boa prática.
Caso não seja, caímos nas opções 2 e 3.
Maravilha, na opção 2 e 3 pensei em mais uma listinha para escolher a melhor forma, a melhor prática. Pensando sempre que o cara que vai manter meu código é um serial killer que sabe onde moro <>.
[list]Criar um hidden na JSP e perguntar quem é quem nessa joça[/list]
[list]Para a última opção da lista anterior, além da solução acima, pensei em fazer o objeto “dizer” o que precisa ser feito com ele. Criar um atributo que diga se ele “quer” se cadastrado, alterado ou excluído. Não me agradou esta solução.[/list]
Vamos às minhas considerações sobre o assunto, lembrando que sou muito fraco ainda em boas práticas:
Na solução 1 da primeira lista, vou povoar meu projeto de servlets, o que pode tornar difícil a manutenção do meu código.
Isto me faz cair nas duas outras soluções. Para isso precisaria criar esse atributo na JSP, para que o Servlet saiba o que fazer ou com quem fazer.
Pois bem, de que tipo seria essa variável?
Se inteira, não sei onde e como manteria a tabela de relacionamento, ou seja, 1 é cadastro, 2 é alteração, 3 é exclusão, por exemplo. Uso inteiros para controlar alguns tipos dentro das classes, mas posso documentar facilmente no javadoc.
Se String como evitar erros bobos e, inclusive no desenvolvimento, saber o que foi colocado ao certo. Exemplo: cadastro/cadastrar/cadastra. Esse é um dos motivos porque nunca gostei de usar String como variável de controle de nada.
Nos livros que pesquisei sobre o assunto e nos documentos da Web os exemplos são sempre muito simples e não abordam esta questão.
Bem o outro problema, colocado nesta mensagem é o seguinte. Criei um atributo resultadoLogin na classe usuário que me informa se o problema no login foi devido ao nome do usuário ou a senha. Como preciso devolver uma instância de Usuario para a minha sessão, nas JSPs, não poderia retornar apenas o inteiro (devidamente documentado no javadoc), precisava retornar uma instância da classe Usuario com as informações do cabra que fez o login. Queria saber, também, se isso é uma boa prática.
Bem, essas são as minhas questões do momento.
Obrigado!
