Opa! Valeu pela otima explicacao, Gabriel! :D
"gcobr":
Se anlisarmos esse requisitos em um estilo mais OO e mais abstrato, poderiamos chegar a algumas conclusões mais lógicas em relação ao domínio de objetos, que com certeza seria mais "rico".
Um modelo de domínio rico tem algumas vantagens, e a primeira e mais importante de todas é que vc consegue representar, de forma realmente OO, os requisitos do seu sistema, e as funcionalidades dos seus objetos. Se voce parar pra pensar bem, um modelo de objetos anemico (feito de VOs, como no seu caso) é programação procedural, e um objeto que só tem getters e setters não é muito diferente de uma struct em C :(
"gcobr":
- A lógica de validação do pedido e do cliente poderia estar dentro dos respectivos métodos set na classe da venda. Ou poderia haver um método set para associar os 2 ao mesmo tempo.
Pode ser, o importante aqui não é em que método colocar, mas sim que a lógica de negócio de um determinado objeto esteja contida nele, mesmo que através de delegação. Delegacao, alias, faz com que a gente ganhe o melhor dos dois mundos. É possivel, por exemplo, usar o Command Pattern, aliado a Decorators, e se divertir bastante:
public class Cliente ... {
public void addPedido(Pedido p) {
new CommandExecutor(new AddPedido(this, p)).execute();
}
}
public class AddPedido ... {
public AddPedido(Cliente c, Pedido p) {
this.cliente = c;
this.pedido = p;
}
public void execute() {
// ...
// checa todas as regras, joga excecoes, etc
// ...
c.getPedidos().add(p);
p.setCliente(c);
}
}
Dentro do CommandExecuter, voce pode se divertir decorando o command com transacoes, configuracoes extras, etc e tal. Mas quem tá de fora, ou seja, sua interface, não fica nem sabendo sobre o que está debaixo dos panos. O importante aqui é isolar os problemas. Persistência, distribuição e esse tipo de coisa podem ser isolados dentro do seu modelo de objetos, sem que a interface fique se preocupando muito com isso. O que tem de tão horrível em chamar um monte de setXXX() e addXXX() em um objeto de negocio, e quando terminar de trabalhar chamar um save()? ;)
Agora, quanto aos "contras" de se ter um modelo de objetos rico:
"gcobr":
- Teriamos objetos do domínio acessando Session Beans para buscar/validar informações e isso parece muito estranho.
Nao necessariamente. Como eu expliquei acima, os objetos do seu dominio so precisam servir de fachada pra um monte de outras esquisitices por baixo. E, dessas esquisitices, ninguem mais precisa ficar sabendo alem dos seus objetos de negocio ;)
"gcobr":
- Teriamos bastante código nas classes do domínio, aumentando bastante o seu custo de transporte pela rede.
A quantidade de codigo nao aumenta o custo de transporte. A quantidade de dados, sim. Lembre-se que a serializacao não transporta o codigo toda vez que vc serializa um objeto, mas só o estado daquele objeto.
"gcobr":
- A interatividade do formulário com o usuário seria perdida ou sua implementação se tornaria ainda mais complexa do que já é.
Não senhor, e alias muito pelo contrario. Eh possivel fazer TableModels mais inteligentes quando vc trabalha com objetos mais "completos". Uma JTable que representa os Itens de um Pedido pode ser um Observer do Pedido, e adicionar um novo item ao pedido modifica a JTable, e nao o contrario (modificar a JTable causa uma alteracao no Pedido). Mais facil, mais OO, e com certeza usando menos codigo :D
