Retorno de Consultas DAO

Programação Arquitetura
#1

Vou refazer uma pergunta que fiz em um tópico e ficou esquecida.

o que vocês retornam em um metodo de consulta de um DAO quando :

  • é agrupamento

  • com restrição de campos (apenas alguns campos da classe)
    retornam um DTO só com os campos usados ou o objeto inteiro ?

  • campos nulos (ver se o campo é nulo em primitivos)
    usam classes Wrappers ?

Gostaria da opinião de vocês.

#2

Todas as anteriores, depende do caso e necessidade.

#3

1-Um Collection genérica.
2-Independente do que eu precise, retorno o objeto inteiro, quem é responsável pelo tratamento das informações é minha camada de negócio.
3-Não entendi, de qualquer forma retorno sempre o objeto, havendo campos nulos ou não.

#4

depende muito.
ja retornei collections de obj, somente obj com os atributos…
gosto muito de usar uma VO generico, que é um hashmap, so ele trafega dados, crio interfaces para as cosntantes usadas nas chaves.
ele pode conter beans, ou collections de beans, ou wrappers, dependendo do caso.

[]'s

#5

Eu acredito que todos esses usos são válidos, não vejo mal em o seu DAO retornar diretamente DTOs caso em todos use cases dele os valores são enviados para o outro tier sem qualquer processamento.

Não tem problema retornar objetos incompletos caso um dos membros seja um blob de 100megas, por exemplo.

#6

[quote=jgbt]depende muito.
ja retornei collections de obj, somente obj com os atributos…
gosto muito de usar uma VO generico, que é um hashmap, so ele trafega dados, crio interfaces para as cosntantes usadas nas chaves.
ele pode conter beans, ou collections de beans, ou wrappers, dependendo do caso.

[]'s[/quote]

:!: :!: Enterprise HashMap detected :!: :!:

#7

o que quer dizer?

[]'s

#8

Todo muito mete o pau no desenvolvimento com HashMap, mas ele quebra uma galho enorme.
Agora é mais fácil falar “depende da necessidade”.
Pelo menos todo mundo dá sua opinião

Quando me refiro a ver se o campo é nulo em primitivos me refiro no seguinte.

class Funcionario
{
  private  float salario;
  // getters and setters
}


Funcionario f = FuncionarioDAO.consultar();
f.getSalario() // opa como eu vejo se é nulo

ou uso

private Float salario;
// agora eu posso ver se é nulo.
#9

sinceramente, ate gostaria que alguem me desse motivos de não usar hashmap.
qual a diferença de ter 30 beans para trafegar dados, ou ter um unico obj para isso.
quase todos frameworks trabalham com hashmap.
alguem???

[]'s

#10

Eis o problema, tanto com HashMaps quanto com VOs: http://www.martinfowler.com/bliki/AnemicDomainModel.html

#11

ae cv, esse artigo ja foi citado antes e nunca parei p/ ler… :smiley:
vo da uma lida então e posto minhas considerações… :mrgreen:
valew!!

[]'s

#12

VO e HashMaps podem ser usados para transportar dados de um tier para outro. Neste caso não são antipatterns pelo contrário.
Agora que eu entendi é que o autor do artigo condena o uso na camada de domínio e negócios, pois quebra a estrutra OO trabalhando com dados generalizados.

Então cv como você trabalha com dados agrupados.
ex:

a média de salário de departamentos. Agrupando por departamento e trazendo o nome de cada responsável.
onde departamento , responsável seriam entidades diferentes.

Para não usar HashMap só vejo DTO.

#13

Se voce quer tanto a media de salario de um departamento, pq nao ter um metodo Departamento.getMedia(), que calcula a media baseando-se nos salarios dos funcionarios que fazem parte dele?

#14

blz, entendi a sua abordagem, mas fica a duvida:
o que o Departamento.getMedia() retornaria, ja que tem dados agrupados de 2 entidades? VO? HashMap? :mrgreen:

[]'s

#15

blz, entendi a sua abordagem, mas fica a duvida:
o que o Departamento.getMedia() retornaria, ja que tem dados agrupados de 2 entidades? VO? HashMap? :mrgreen:

[]'s
[/quote]

Double ou Float nao? :mrgreen:

]['s

#16

Nao, Joao… Departamento eh um objeto do seu dominio. Assim como tem getMedia():BigDecimal, tem getResponsavel():Funcionario, e tem getFuncionarios():Set… :wink:

Ele nao eh um VO, pq ele nao eh um objeto que serve so pra ser estuprado por um DAO, que manda pro controller fazer autopsia. Ele (oooooh, vejam so!) contem as regras de negocio relacionada a departamentos! :slight_smile:

#17

[quote=cv]Nao, Joao… Departamento eh um objeto do seu dominio. Assim como tem getMedia():BigDecimal, tem getResponsavel():Funcionario, e tem getFuncionarios():Set<Funcionario>… :wink:

Ele nao eh um VO, pq ele nao eh um objeto que serve so pra ser estuprado por um DAO, que manda pro controller fazer autopsia. Ele (oooooh, vejam so!) contem as regras de negocio relacionada a departamentos! :)[/quote]

blz, acho que agora rolou, objeto do dominio… ele é o responsavel pelas operações, ja me devolvendo o que interessa. tenho que começar a ver as coisas de maneira diferente… :mrgreen:

valew!!

[]'s

#18

Isso que o CV colocou é o OO puro.
Mas isso não gera perda de performance.
Cada método faria uma consulta diferente ?

Não vivemos um mundo acadêmico.
Essas abordagens OO são bonitas mas como temos limitações tecnológicas temos que usar recursos que se baseam no bom senso.
é a balanca entre clareza de código X funcionalidade

Também volta avelha discussão do tráfego da rede para objetos remotos.
Isso na camada de negócio é fantastico, mas na camada de serviço tem que ser DTO ou HashMap mesmo.

#19

[quote=jprogrammer]Isso que o CV colocou é o OO puro.
Mas isso não gera perda de performance.[/quote]

Isso foi uma pergunta? Se foi, a resposta eh nao. Ganho em produtividade e qualidade do codigo, sim.

Nao, cada metodo faz o que tem que fazer, e nao mais que isso :wink:

#20

[quote=jprogrammer]I
Isso na camada de negócio é fantastico, mas na camada de serviço tem que ser DTO ou HashMap mesmo.
[/quote]

Defina “Camada de Serviços”…