Impasse entre lentidão e quebra de camadas.

Pessoal, bom dia !

Considerem o exemplo abaixo:

No método "getDataUltimaVenda" o correto seria fazer um "FOR" e ficar procurando qual seria a última data de venda e retorná-la. Porém tenho o receio que isso com o tempo possa ficar lento, porque o número de pedidos irá aumentando com o tempo.
Uma solução seria fazer uma busca no banco de dados, porém não devo fazer acesso ao banco a partir das minhas classes de domínio.

Gostaria de sugestões de como resolver isso ?

Exemplo das classes:

GUJ Master Membro desde: 17/04/2006 15:29:07 Mensagens: 1491 Offline

cara,

vc pode fazer um select max data pedido, vc pode ter no seu DAO uma sql normal, que nao necessite usar hql ou criteria.

T+

alissonvla wrote:cara,

vc pode fazer um select max data pedido, vc pode ter no seu DAO uma sql normal, que nao necessite usar hql ou criteria.

T+

Vlw pela resposta.
Mas então cara, tanto faz ser hql, criteria ou não. Isso não mudaria em nada.
A questão é, como fazer isso no "get" que esta dentro do produto sem ferir a camada e ficar fazendo "FOR" ? Pois teoricamente essa seria forma correta.

GUJ Master Membro desde: 17/04/2006 15:29:07 Mensagens: 1491 Offline

entao,

eu no meu caso faria esse seu caso passando pela camada de negocio e depois camada de persistencia, não colocaria isso direto na sua entidade.

t+

JavaEvangelist Membro desde: 02/05/2006 19:23:53 Mensagens: 363 Offline

uma dica, não sei se vale pra vc

eu faço assim

Select minhadata From tabela Order By minhadata desc Limit 1;

HelloWorld Membro desde: 26/04/2011 08:09:57 Mensagens: 14 Offline

alissonvla wrote:entao,

eu no meu caso faria esse seu caso passando pela camada de negocio e depois camada de persistencia, não colocaria isso direto na sua entidade.

t+

nei.junior e alissonvla

Essa sugestão seria uma solução, porém ao meu ver não fica tão OO quanto se estivesse dentro da entidade, a não ser que suas entidades sejam apenas objetos de valor (o que daria outra discussão enorme). Além disso, se colocar isso na camada de negócio ou persistência eu ainda vejo uma dificuldade caso você tenha que exibir uma lista (uma table por exemplo) com os atributos do seu produto e se esse valor 'dataUltimaCompra' tiver que ser listado, terá um certo trabalho para poder exibir isso.

danilo.magrini wrote:
nei.junior e alissonvla

Essa sugestão seria uma solução, porém ao meu ver não fica tão OO quanto se estivesse dentro da entidade, a não ser que suas entidades sejam apenas objetos de valor (o que daria outra discussão enorme). Além disso, se colocar isso na camada de negócio ou persistência eu ainda vejo uma dificuldade caso você tenha que exibir uma lista (uma table por exemplo) com os atributos do seu produto e se esse valor 'dataUltimaCompra' tiver que ser listado, terá um certo trabalho para poder exibir isso.

Exatamente, concordo com o que o danilo.magrini disse.

GUJ Master Membro desde: 17/04/2006 15:29:07 Mensagens: 1491 Offline

cara,

eu penso no seu caso, como se fosse uma regra de negocio e não uma propriedade de uma entidade.
esse é meu pensamento.

t+

Começo a pensar que o método getDataUltimaVenda não deva estar na classe Produto, o que acham?

flws

Vamos lá então. Você não quer ferir o seu modelo e isso é o correto a se fazer.
Entretanto, vejo um grande problema no seu modelo, que é o Produto ter q saber quando ele foi vendido pela última vez. Ao meu ver, isso vai contra a aquele princípio da responsabilidade única (SRP).

O modelo que eu faria é o seguinte: ter um outro objeto que, dado um produto, ele saiba responder quando aquele produto foi vendido pela última vez. Mais ou menos assim

nei.junior wrote:Exatamente, concordo com o que o danilo.magrini disse

Acho que vc irá afetar seu modelo incluindo uma responsabilidade de outros objetos relacionados a view.

flws

GUJ Master Membro desde: 17/04/2006 15:29:07 Mensagens: 1491 Offline

e pra mim, tudo que envolve sql, faz parte da regra de negocio.

t+

HelloWorld Membro desde: 26/04/2011 08:09:57 Mensagens: 14 Offline

ruivo wrote:Vamos lá então. Você não quer ferir o seu modelo e isso é o correto a se fazer.
Entretanto, vejo um grande problema no seu modelo, que é o Produto ter q saber quando ele foi vendido pela última vez. Ao meu ver, isso vai contra a aquele princípio da responsabilidade única (SRP).
[/code]

Aqui é onde entra as enormes discussões sobre arquitetura. Ao meu ver é responsabilidade sim do Produto saber a dataUltimaVenda, pois se isso fere o princípio da responsabilidade única então teriamos que ter objetos ProdutoCodigo, ProdutoDescricao, ProdutoPreco, ProdutoUnidade, etc;

danilo.magrini wrote:
Aqui é onde entra as enormes discussões sobre arquitetura. Ao meu ver é responsabilidade sim do Produto saber a dataUltimaVenda, pois se isso fere o princípio da responsabilidade única então teriamos que ter objetos ProdutoCodigo, ProdutoDescricao, ProdutoPreco, ProdutoUnidade, etc;

De maneira alguma. O que é uma venda? Nada mais é que um pedido finalizado. E é um pedido que tem um produto, não o contrário. Pensa numa garrafa. Ela não tem gravada nela quando foi vendida. Agora, se pensar na nota fiscal, lá estarão as referências para os produtos que foram vendidos, com as datas e valores pagos pelo consumidor.

Se você quiser saber qual a data que um produto foi vendido pela última vez, você deve perguntar para os pedidos (ou notas fiscais) qual a última vez que aquele produto aparece, e não perguntar pro produto quando ele foi vendido, que não faz muito sentido.

Isso é um dilema de arquitetura mesmo. Na minha opiniao, a data da ultima venda é uma regra de negocio, como tambem data da ultima compra, media de preco vendida, meses onde ocorre maior venda, etc. Para usar estas informacoes calculadas em uma table ou um relatorio, o melhor seria fazer estes calculos e possiveis acessos ao BD em uma classe DAO, que retornasse, por ex., uma lista de produtos com data de ultima venda. Eu inclusive crio uma classe auxiliar e faco no DAO um "SELECT new classeAuxiliarXXX(lista de campos) FROM... WHERE...", e nas tables/relatorios uso a classe auxiliar, pois fica facil acessar todos os campos, que podem vir de Produto, Venda, Cliente, etc.

Notícias, artigos e o maior fórum brasileiro sobre Java