DAO e DTO == Bobagem?

Assuntos Gerais Agile
#41

A primeira edição (a que tem em português) do J2EE Patterns Catalog fala em VO, a versão online (e imagino que a atual edição americana) mudaram o nome para TO, apesar de manter diagramas antigos como VO, e esse padrão é chamado por Martin Fowler (e é um nome mais genérico) de DTO.

#42

Ahh… estava lendo é imaginando que diabos é este padrão DTO valeu RodrigoW e pacalcado… por me explicar que é a VO…

Se eu estiver equivocado porfavor alguem me corrigia… mas estava sendo discutido que se utilizar VO com DAO, não é muito elegante ??? pq ???

#43

Porque você deve usar DTOs apenas em ambientes altamente distribuídos, não para trocar dados entre camadas, para isso use objetos de domínio.

#44

[quote=“jack_-_ganzha”]BOs deveria ser algo assim:

[code]public class People {
private String name;
private String bla;
…
//set e gets

public boolean save() {
// eu me salvo, mesmo que precise delegar para alguem
}
}[/code]
Ao passo que com modelos burros o codigo fica:

[code]public class People {
private String name;
private String bla;
…
//set e gets
}

// em algum momento…
service.save(people);
[/code][/quote]

[quote=“pcalcado”][quote=“danieldestro”]
Usar um DAO de dentro do seu BO me faz mais sentido.[/quote]

Você vai acoplar seus objetos de negócio á sua camada de persistência. Vai misturar duas camadas.

Seus objetos de negócio são responsáveis pela lógica de negócios, e não por mapeamento objeto-relacional.[/quote]

Se um BO pode ter um método save(), mas não deve acoplar o DAO(segundo pcalcado), como delego a tarefa de salvar para o DAO? Com o ‘modelo burro’ descrito pelo jack_-_ganzha me parece claro como fazer isso!

#45

Acho que a confusão ocorre em parte pelo excesso de siglas. Nesta lista abaixo todos tem a mesma função:
[list]
VO - Value Object
DTO - Data Transfer Object
TO - Transfer Object
[/list]

Um exemplo:

public class TO {
    private Map data = new HashMap();

    public int getSize() {
        return this.data.size();
    }

    public void setValue(final String key, final Object value) {
        this.data.put(key, value);
    }

    public Object getValue(final String key) {
        return this.data.get(key);
    }

    public void remove(final String key) {
        this.map.remove(key);
    }

}

Estas são as funcionalidades básicas, pode-se acrescentar algumas coisas a mais. A idéia é simplifica o modelo considerando-se beans com muitos parâmetros e muitos getters e setters.

Na definção da Sun, este pattern server para:

Eu particularmente prefiro utilizá-lo assim, de forma genérica mesmo. Sem especializar para ClientVO ou coisa similar.

Para utilizá-lo gosto de usar reflexão para fazer o wrapper entre os tipos quando necessário. Mas normalmente o bean comum já é suficiente para meu uso. Aprendi uma coisa que tem me salvado tempo… Usar a metodologia KISS (Keep It Simple Sucker) :smiley:

T+

#46