Paginação e Ordenação em DDD

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Thiago Senna wrote:

sergiotaborda wrote:O problema de não usar QueryObject conjuntamente (cooperação) com um outro objeto - neste caso o repositorio que faria o papel de interpreter - é o acoplamento. Com um QO desassoiado do repistorio vc pode ter muito mais flexibilidade porque pode mandar o mesmo QO para reposiotorios com implementações diferentes (um real e um de teste, por exemplo).

Entendo, entendo. Mas em minha opinião este esforço não tem valido a pena.

Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.

Nada contra em implementar um bom OO, mas a real é que no fim, se vc juntar tudo que você implementou para fazer tudo ficar bonitinho praticamente vira um framework novo. Não é a toa que você está desenvolvendo o MiddleHeaven, certo?

Fazer bom OO é mais facil que fazer mau OO. Eu sei que é dificil de acreditar, mas é verdade. Vc codifica menos e com mais gosto.
O MiddleHEaven é por causa do principio DRY , porque ficar implementando a mesma coisa 300 vezes ? e já que vai fazer , faz direito ( easy said than done)

Infelizmente aplicar patterns, OO, separação de camadas e essas coisas de forma bonitinha é sofrido demais. Principalmente hoje dependendo de qual framework vc está adotando.

Hum... provavelmente porque usa os framework errados.Escolher frameworks com flexibilidade suficiente não é simples.

Hoje, utilizando wicket, ainda posso colocar o interpreter fora do repositorio. Eu poderia numa boa criar um componente de UI que fizesse a interpretação do QueryObject. Melhor fazer isso do que criar o componente de UI, que chama o repositório e que por fim, chama o QueryObject. IMHO é muita delegação. A maioria dos projetos não precisam ser defensivos a este ponto, acho. E vocês, o que acham?

Para mim QO é um objeto de contexto , ele viaja entre camadas , mas não desde da UI. Essa de fazer um interpretador na UI não entendi. O interpretador deveria estar perto do repositorio / hibernate / entitymanger e não longe na UI.
Em vb usava smart-UI e sempre achei acoplado demais. Por isso que gosto de java e OO porque vc pode (deve?) não usar smart-UI.

smart-UI para mim é usar Jquery fazendo tabs e menus dinamicos e até ajax... mas as logicas de manipulação, qeury, etc é tudo no codigo back-end por causa da reusabilidade.

Pessoal, que bom que o post tenha dado esta discursão tão produtiva para a comunidade.

realmente é bom ter várias cabeças pensando junto, estou implementando uma abordagem de Fluent interfaces para o meu Repositorio onde tenho métodos que fazem chamada da seguinte forma:

a linha 1 me retorna uma lista de todos os usuários com o nome carlos alberto que estejam ativos e ordenado por nome na primeira pagina e retorna 40 registros.
a linha 2 faz a mesma coisa mas me retorna a contagem.

caso tenha um critério mais especifico implemento um método dentro do repositorio especificamente para atender a demanda do mesmo.

assim o cliente do repositorio pode selecionar de forma livre os dados que deseja e ainda implementar a paginação e ordenamento.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

sergiotaborda wrote:Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?

sergiotaborda wrote:Fazer bom OO é mais facil que fazer mau OO. Eu sei que é dificil de acreditar, mas é verdade. Vc codifica menos e com mais gosto.

Claro, sem dúvida.

sergiotaborda wrote:O MiddleHEaven é por causa do principio DRY , porque ficar implementando a mesma coisa 300 vezes ? e já que vai fazer , faz direito ( easy said than done)

Muito boa sua iniciativa. O código parece bem legal também. No entanto, tenho preferido evitar todo este esforço. É uma guerra que nunca termina para seu projeto não ficar acoplado a framework nenhum. Enquanto não houver algo pronto que eu possa reaproveitar prefiro resolver as coisas de formas simples e facilmente refatoráveis. Acho que ambas idéias são aceitáveis.

sergiotaborda wrote:Hum... provavelmente porque usa os framework errados.Escolher frameworks com flexibilidade suficiente não é simples.

Será mesmo? Acho que fazer o contrário é tão difícil quanto, ou seja, adaptar o domínio aos benefícios dos frameworks.

sergiotaborda wrote:Para mim QO é um objeto de contexto , ele viaja entre camadas , mas não desde da UI.

Se eu optar por não usar repositórios, vou fazer como? No meu contexto usar o QueryObject como se fosse um Bean junto com as classes de UI tem trazido ótimos benefícios e reduzido muito código.

sergiotaborda wrote:Essa de fazer um interpretador na UI não entendi. O interpretador deveria estar perto do repositorio / hibernate / entitymanger e não longe na UI.

Pois é, enfiei o hibernate dentro das classes de UI.

sergiotaborda wrote:Em vb usava smart-UI e sempre achei acoplado demais. Por isso que gosto de java e OO porque vc pode (deve?) não usar smart-UI.

smart-UI para mim é usar Jquery fazendo tabs e menus dinamicos e até ajax... mas as logicas de manipulação, qeury, etc é tudo no codigo back-end por causa da reusabilidade.

O que estou implementando não é tão radical quanto se propõe o Smart-UI. Só que o ideal é que o Domain possa ser facilmente acessado e manipulado por este "Smart-UI". Por isso o repositorio pra mim não tem ajudado. Mantê-lo implica em escrever bem mais código. Simples assim.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

euprogramador wrote:Pessoal, que bom que o post tenha dado esta discursão tão produtiva para a comunidade.

realmente é bom ter várias cabeças pensando junto, estou implementando uma abordagem de Fluent interfaces para o meu Repositorio onde tenho métodos que fazem chamada da seguinte forma:

usuarioRepositorio.igual("nome","Carlos Alberto").igual("ativo",true).ordenadoPor("nome",descending).listagem(1,40); usuarioRepositorio.igual("nome","Carlos Alberto").igual("ativo",true).ordenadoPor("nome",descending).contagem();

Se se trata de fluent interface, eu entendo que você está listando repositórios ao invés de usuários. Como eu li:

"listagem de usuarioRepositorio igual Carlos Alberto e igual ativo, ordeando por nome."

Talvez se fosse
Aí sim, ficaria bem melhor.
Ainda daria pra otimizar, já que faz parte do usuário mesmo, pode diminuir o uso de parametros e passar a usar metodos com o nome real e de quebra, ainda eliminaria a dependencia que o repositorio tem da estrutura do seu aggregate. Imagine se vc remover o campo ativo. Causará side effect em várias chamadas desse repositorio.

Outra coisa que reparei é que nesse caso aí você está criando um query object builder, como o taborta mencinou no outro tópico. Esse código é muito bonito pra infra estrutura, mas no repositório eu colocaria algo mais objetivo. Para ter uma idéia melhor do que estou falando, procure ler sobre o Supple Design. Ele determina práticas como IntentionReavelingInterfaces de forma que sua interface revela o que deve ser feito.

Pode chamar esse query object builder direto de dentro do repositorio se quiser, mas leve em consideração o que eu escrevi acima. =)

feliperod wrote:
Outra coisa que reparei é que nesse caso aí você está criando um query object builder, como o taborta mencinou no outro tópico. Esse código é muito bonito pra infra estrutura, mas no repositório eu colocaria algo mais objetivo. Para ter uma idéia melhor do que estou falando, procure ler sobre o Supple Design. Ele determina práticas como IntentionReavelingInterfaces de forma que sua interface revela o que deve ser feito.

Pode chamar esse query object builder direto de dentro do repositorio se quiser, mas leve em consideração o que eu escrevi acima. =)

O que acontece é o seguinte eu tenho os ManagedBeans do jsf que pertence a camada de aplicação, e coloquei a interface do repositório na camada de dominio e a implementação na infraestrutura, desta forma que demonstrei o repositório realmente sabe demais sobre a infraestrutura, o que recomenda então é criar um objeto que será responsável por acessar o banco e ficará na infraestrutura, e tanto o managed bean e o repositório o acessaria?

ficando assim

O repositório seria também poderia acessar o QueryObject, mas agora ele tem uma interface mais especifica como:

Com a seguinte implementação:

Seria assim?

Outra, o que tenho notado com DDD é que o código de negócio (Service) fica bem pequeno, mas temos muito código nas camadas para suportar o serviço, é assim mesmo?

feliperod wrote:
procure ler sobre o Supple Design. Ele determina práticas como IntentionReavelingInterfaces de forma que sua interface revela o que deve ser feito.

Obrigado pela referência estou olhando...

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

euprogramador wrote:
O que acontece é o seguinte eu tenho os ManagedBeans do jsf que pertence a camada de aplicação, e coloquei a interface do repositório na camada de dominio e a implementação na infraestrutura, desta forma que demonstrei o repositório realmente sabe demais sobre a infraestrutura, o que recomenda então é criar um objeto que será responsável por acessar o banco e ficará na infraestrutura, e tanto o managed bean e o repositório o acessaria?

ficando assim
... // método do managed bean public void recuperarListagem(){ listaDeClientes = usuario.igual("nome","Carlos Alberto").igual("ativo",true).ordenadoPor("nome",descending).listagem(1,40); } ...

talvez assim fique melhor. Não sei.. tem que avaliar o caso.

euprogramador wrote:
O repositório seria também poderia acessar o QueryObject, mas agora ele tem uma interface mais especifica como:
... // método da interface do repositorio public List<Usuario> recuperarUsuariosNaoAtivos(); ...
Seria assim?

Acho que essa interface pro repositorio está boa sim. O nome do método é bem explicativo. Talvez fique melhor se você achar um jeito de dizer que é ordenado. Isso normalmente é resolvido por named paramaters em linguagens dinâmica. No Java pode ser inviável. Mas vale tentar.

euprogramador wrote:
Outra, o que tenho notado com DDD é que o código de negócio (Service) fica bem pequeno, mas temos muito código nas camadas para suportar o serviço, é assim mesmo?

O Código de negócio deve ficar na camada de domain. Nos Services, Entities, Value Objects.
É um assunto mesio extenso pra explicar pelo forum sem ser abstrato demais. Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Mas de qq forma, as outras camadas não devem conter regras de negócio. Verifique se o Service que você mencionou é o Service que o DDD menciona (conceitualmente). Verifique se a sua camada de domain possue um limite claro... Verifique se cada camada está cumprindo unica e exclusivamente o seu papel.
Ah.. cuidado pra não confundir regra de negócio com regra de apresentação.

E é isso. =)

feliperod wrote:
Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Onde vai ser? eu sou de brasília.

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

euprogramador wrote:

feliperod wrote:
Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Onde vai ser? eu sou de brasília.

Vai ser em sampa... =(
Mas quem sabe a gente marca um em Brasilia qualquer dia desses. Só arrumar lugar e rachar as despesas da viagem entre a galera aí que eu vou. =)
QQ coisa me contata em PVT.

feliperod wrote:
Onde vai ser? eu sou de brasília.

Vai ser em sampa... =(
Mas quem sabe a gente marca um em Brasilia qualquer dia desses. Só arrumar lugar e rachar as despesas da viagem entre a galera aí que eu vou. =)
QQ coisa me contata em PVT.

De boa, a gente pode ver sim, valeu;

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Thiago Senna wrote:

sergiotaborda wrote:Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.

sergiotaborda wrote:O MiddleHEaven é por causa do principio DRY , porque ficar implementando a mesma coisa 300 vezes ? e já que vai fazer , faz direito ( easy said than done)

Muito boa sua iniciativa. O código parece bem legal também. No entanto, tenho preferido evitar todo este esforço. É uma guerra que nunca termina para seu projeto não ficar acoplado a framework nenhum.

Isso não é dificil, é impossivel. toda a aplicação é amarrada a aquilo que se chama a plataforma de aplicação.
A plataforma de aplicação é um "framework" que vc usa para criar a aplicação. normalmente vc cria esta plataforma
fazendo uma "mushup" de frameworks que tratam partes especificas (Spring para Ioc , Hibernate para persistencia, JSF para apresentação, CFX para webservices, Commons-upload para tratar downlods , etc...) Só que é meio frankeinstein. Vc não isola esses frameworks e um dia vc bate com "putz não dá para fazer isso no X" onde X é um dos frameworks.

Essas plataformas frankeinstein funcionam bem durante um tempo, mas não para sempre.

Enquanto não houver algo pronto que eu possa reaproveitar prefiro resolver as coisas de formas simples e facilmente refatoráveis. Acho que ambas idéias são aceitáveis.

Já existe algo pronto. os frameworks "on rails" são isso mesmo. E são mais ainda fazendo integração com ferramentas como compiladores, mavem e outros. o Grails é um exemplo prático. Ele usa Spring, hibernate , etc ,mas vc não precisa vê esses frameworks.

O MiddlHeaven não segue o caminho on rails, mas é uma plataforma de aplicação. A ideia é dependender apenas dela e deixar ela depender de quem for preciso.

sergiotaborda wrote:Hum... provavelmente porque usa os framework errados.Escolher frameworks com flexibilidade suficiente não é simples.

Será mesmo? Acho que fazer o contrário é tão difícil quanto, ou seja, adaptar o domínio aos benefícios dos frameworks.

Um exemplo, o jasperReports é excelente para integração com outros frameworks "acima". Já o JFreeReport é uma porcaria.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

sergiotaborda wrote:

Thiago Senna wrote:

sergiotaborda wrote:Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.

Não utilizo servidor de continuidade. Testo sem a camada de UI numa boa. Testo Domain + Persistência pois não acho necessário separá-los. Para casos onde é muito importante testar o negócio sem persistência é só usar mock. Qual é a dificuldade nisso?

JavaTeenager Membro desde: 07/11/2006 14:10:54 Mensagens: 184 Offline

Thiago Senna wrote:

sergiotaborda wrote:

Thiago Senna wrote:

sergiotaborda wrote:Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.

Crio os testes automatizados numa boa. Conclusão precipitada, não acha?

Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.

Não utilizo servidor de continuidade. Testo sem a camada de UI numa boa. Testo Domain + Persistência pois não acho necessário separá-los. Para casos onde é muito importante testar o negócio sem persistência é só usar mock. Qual é a dificuldade nisso?

Não vou opinar se está certo ou se está errado. Mas eu daria uma dica para você ler sobre benefícios do TDD. O TDD consiste em escrever o teste antes do código. Isso facilita o design de cada classe. Individualmente. Nesse caso, por nào separar o Domain da persistência, fica claro que não são testes unitários.

Outra coisa é que dificuldade para testar individualmente siginifica, na maioria dos casos, problemas de design.

Vale a pena investigar.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

feliperod wrote:Não vou opinar se está certo ou se está errado. Mas eu daria uma dica para você ler sobre benefícios do TDD. O TDD consiste em escrever o teste antes do código. Isso facilita o design de cada classe. Individualmente. Nesse caso, por nào separar o Domain da persistência, fica claro que não são testes unitários.

Outra coisa é que dificuldade para testar individualmente siginifica, na maioria dos casos, problemas de design.

Vale a pena investigar.

Sempre que escrevo testes é utilizando TDD. Se eu não escrever os testes primeiros eu tenho certeza q não vou escrever os testes depois.

Talvez o problema não esteja exatamente nos testes. Como puderam notar, sou um tanto "revoltado", rsrs. Eu meio que cansei desta arquitetura defensiva onde se faz tudo pensando de que no futuro alguem vai mudar o mecanismo de persistência, de que derrepente o cliente muda o framework de UI entre outras coisas.

Sempre que pegamos um projeto e precisamos produzir vejo meu tempo sendo consumido criando interfaces, sua respectiva implemetação ao invés de simplesmente criar a implementação. Isso é revoltante pq analisando qualquer outra linguagem vemos que essa separação absurda só acontece na comunidade java. Resumindo.. simplesmente quero resolver o problema e acabo me vendo a todo momento lidando com um monte de burocracia que todo programador acha que não pode viver sem.

Oras, se um desenvolvedor conhece bem os benefício de criar sua arquitetura com tudo separadinho, se ele por acaso querer juntar tudo de novo será que não pode sair alguma coisa boa daí?

Com certeza separar tudo não está errado. Mas juntar tudo denovo é o que estou testando fazer. É legal remar contra a maré

UPDATE: Obs: Alguns dos meus testes não se enquadram como teste unitário. Mas já é algum teste automatizado e aplico TDD.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Thiago Senna wrote:
Oras, se um desenvolvedor conhece bem os benefício de criar sua arquitetura com tudo separadinho, se ele por acaso querer juntar tudo de novo será que não pode sair alguma coisa boa daí?

Não pode. Esta é a vantagem de entender os principios de OO.
Vc pode pensar , dentro do seu espectro de experiencia, que assim é melhor. Pode ser mais rápido, mas não é melhor.

O desacoplamento não se faz porque o banco pode mudar, mas porque se usam 2 bancos (um "real" e um de testes).
O desacoplamento não é uma decoração, é uma necessidade. Mas se vc não desacopla , bom é com vc. Sempre pode refactorar depois

O ponto é o seguinte : aquilo que é bem feito por design não precisa se refactorado. Refactorar , ao contrário do que muita gente pensa, não é uma tecnica salva tudo mas sim a exumação de código morto, mal feito, ruim, acoplado, etc... Refactorar serve para tornar seu codigo melhor, mas se seu codigo já nasce bom, não ha porque refactorar = não se perde tempo com isso.

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