Eu já tive que fazer documentação RUP para ASP clássico :evil: :evil: :evil:
Hoje eu penso da seguinte forma:
Existem duas maneiras (basicamente) de fazer um sistema.
A primeira é a clássica: o banco de dados é o meu pastor, soterd procedure não me faltará. Esse é o modelo do lozano, onde o importante é a estrutura do banco de dados. Isso funciona e é bem eficiente em muitoas casos.
A outra é uma abordagem OO. Aqui os objetos são o seu sistema. O banco de dados é só uma fotografia doe stado dos objetos no isntante atual (ou no passado, se histórico).
Na primeira abordagem você semrpe vai tender á modelar os seus objetos como structs burras, proque você está refletindo as tabelas do SGBD, que são assim.
Quando inicio alguma modelagem hoje eu tento simplesmente esquecer que existem bancos de dados. Enquanto modelando a camada de negócios, meus objetos são sempre eternos em memória, automaticamente salvos. Geralmente eu coloco a lógica que “sabe” quando é hora de persistir na camada de aplicação, isso é ruim mas pelo menos a camada de negócios é livre para fazer o que tem que fazer.
Para persistir objetos, é relativamente simples (não necessariamente bonito ou fácil) seguir um prático idioma: Faça seus clientes conhecerem Interfaces de negócio apenas.
Vamos lá, meu clássico exemplo:
interface Usuario{
public boolean auteticar(String senha);
public String getLogin();
public void setSenha(String senha);
}
class UsuarioDeVerdade implements Usuario{
private String senha;
private String login;
public String getSenha(){...}
}
O que se passa aqui?
Eu quero que os clientes possam apenas alterar a senha (sem saber o conteúdo anterior) ou compará-la com outra string. A interface usuario me oferece esses serviços. Ah, esqueça o noem horrivel da classe ![:stuck_out_tongue: :stuck_out_tongue:](//www.guj.com.br/images/emoji/twitter/stuck_out_tongue.png?v=5)
Para persistir meus Usuarios, eu vou precisar saber a senha para colcoar no SGBD.
Uma solução é uma fábrica de usuários:
class UsuafioFactory{
public Usuario novoUsuario(String login){
UsuarioDeVerdade u = new UsuarioDeVerdade(login);
return u;
}
}
E deixe seu DAO 9ou coisa que o valha) conehcer a implementação do usuário, apra que pegue os campos “escondidos” como senha.
É a melhor solução? Provavelmente não. É bonito? Definitivamente não. Funciona? Comigo tem funcionado.
Alguém tem em algo melhor pra propôr?