DDD - Objetos de consulta usando ORM - o que vcs acham?

[Alessandro de Souza]

Amigos,

em outros posts já vi alguns dos arquitetos dando sugestão para usar objetos de consulta retornando DTO´s ou algo assim, visto que podemos ganhar performance, até mesmo, não passando pelo ORM. Esta sugestão também pesa pelo fato de que repositórios (DDD) não lidam bem com consultas, visto que retornam entidades inteiras, e para uma consulta as vezes precisamos apenas mostrar alguns dados (CPF, NOME, ENDEREÇO).

Até ai, tudo legal.

A minha dúvida é: eu ganho performance usando ADO.NET direto para extrair estes dados (com sql ad-hoc) ao invés de usar um ORM também criando apenas os DTO´s ?

Alguém teve experiência com este tipo de situação?

[]´s

Alessandro

[tucaz]

Eu queria entender qual a origem da idéia de que usar um ORM é mais
lento do que efetuar uma consulta ad-hoc.

Um ORM vai executar a mesma (ou até melhor) query que você vai
executar quando cria queries ad-hoc/inline e vai popular os objetos
(DTOs, whatever) do mesmo jeito que se você usasse queries ad-hoc.
Além disso, ele vai te oferecer outros mecanismos que podem ajudar e
não atrapalhar. Não faz muito sentido pensar que usando um ORM vai ser
mais lento.

Att.,
Tuca

On Aug 31, 9:58 am, Alessandro de Souza

[Cassiano Kuss]

Talvez a colocação do Alessandro seja executar as querys e simplesmente mostrar os dados retornados sem gerar objetos.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Alessandro de Souza]

Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO, para levar os dados dos objetos de consulta até a interface gráfica. De fato devo popular uma lista com estes DTO´s.

E pelo que entedi, não há ganho de performance em deixar de usar um ORM.

Eu só queria ouvir alguém que já teve experiência com este tipo de situação. Apesar de que todo sistema precisa de consulta né...  problema é que quem usa DDD as vezes retorna dos repositórios uma lista das entidades, ai sim é um erro pq consome-se muitos recursos que não serão utilizados, visto que, seria apenas para mostrar os dados.

Ah.. TUCA entendi perfeitamente.. grato pela sugestão...

[]´s

[Humberto Marchezi]

Mesmo que se queira retornar dados ao invés de uma lista de entidades, um bom ORM como o NHibernate pode fazer isso para você.

Ex:

( from c in Repositorio<Cliente>().Query() // Retorna um IQueryable<Cliente>
  where c.DataNascimento = XXXXXX && c.Nome like XXXXXX
  select c.Nome, c.Endereco, c.Estado.Descricao, .... )   // Essa consulta retorna apenas os dados necessários

Obs: Nos bastidores, o NHibernate-Linq vai gerar o SQL correspondente a consulta acima.

2010/8/31 Alessandro de Souza <alessandr...@gmail.com>

--
Humberto C Marchezi
---------------------------------------------------------

[Stupied4ever]

@tucaz,
cara posso estar errado, mas todos os benchmarcks que eu encontro fala
que ORMs são mais lentos.
Ex: http://alexpinsker.blogspot.com/2007/07/benchmarking-linq-vs.html
Não estou justificando o não uso, eu pessoalmente gosto muito de usar
ORMs por melhorar muito a manutenabilidade. Mas estou ciente que estou
abrindo mão de um pouco de "performance".
Caso você tenha algum benchmark que demonstre o contrario me avise.




[]'s

On 31 ago, 10:20, Alessandro de Souza <alessandro.de.so...@gmail.com>
wrote:

> Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO, para
> levar os dados dos objetos de consulta até a interface gráfica. De fato devo
> popular uma lista com estes DTO´s.
>
> E pelo que entedi, não há ganho de performance em deixar de usar um ORM.
>
> Eu só queria ouvir alguém que já teve experiência com este tipo de situação.
> Apesar de que todo sistema precisa de consulta né...  problema é que quem
> usa DDD as vezes retorna dos repositórios uma lista das entidades, ai sim é
> um erro pq consome-se muitos recursos que não serão utilizados, visto que,
> seria apenas para mostrar os dados.
>
> Ah.. TUCA entendi perfeitamente.. grato pela sugestão...
>
> []´s
>

> Em 31 de agosto de 2010 10:17, Cassiano Kuss <cassianok...@gmail.com>escreveu:
>
> > Talvez a colocação do Alessandro seja executar as querys e simplesmente
> > mostrar os dados retornados sem gerar objetos.
>

> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >  --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

[Alessandro de Souza]

Perfeito Humberto.

A questão é que eu tendo um DTO definido, fica mais fácil (documentado) exatamente o que será retornado pelo meu objeto de consulta (quais campos).

Mais sei também que se eu fizer um 'select new objeto...' ele popula uma lista com os DTO´s.

[]´s

[Diullei Gomes]

Fato é: existe realmente uma "indireção" nos métodos do NHibernate até que o objeto seja recuperado. Muitas chamadas de métodos, criação de objeto "on-the-fly" e por aí vai até que tenhamos o nosso resultado. Olha que já me aventurei no código do NH e vi isso muito bem. Mais não credito que isso gera alguma perda de performance significativa, em relação a construir uma chamada direta utilizando ADO.NET e ainda que gerasse, o ganho de produtividade compensa muito na minha opinião.

2010/8/31 Flávio Henrique de Carvalho <flaviohenriq...@gmail.com>

Tuca, este post tem muito haver com um outro que eu havia lançado ontem e por isto quero responder sua pergunta.

A origem de minha dúvida e também do Alessandro sobre a queda de performance no uso de ORM, vem do fato da adição de uma nova camada entre a aplicação e o banco. Pensa comigo senão parece lógico, pensar que a consulta que ia diretamente do framework  para o banco de dados e executava uma instrução, agora passa por uma nova camada (ORM) é interpretada por ela e só depois vai ao banco. Estou sendo simplista demais, eu sei, e não sei como funciona a codificação interna destas arquiteturas. Mas parece claro demais pra mim, que quanto mais camadas adicionamos ao nosso sistema, ganhamos em manutenção e organização, mas perdemos na comunicação entre elas (performance).

Flávio
http://flaviohenriquedecarvalho.spaces.live.com/

Em 31 de agosto de 2010 10:20, Alessandro de Souza <alessandr...@gmail.com> escreveu:

Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO, para levar os dados dos objetos de consulta até a interface gráfica. De fato devo popular uma lista com estes DTO´s.

E pelo que entedi, não há ganho de performance em deixar de usar um ORM.

Eu só queria ouvir alguém que já teve experiência com este tipo de situação. Apesar de que todo sistema precisa de consulta né...  problema é que quem usa DDD as vezes retorna dos repositórios uma lista das entidades, ai sim é um erro pq consome-se muitos recursos que não serão utilizados, visto que, seria apenas para mostrar os dados.

Ah.. TUCA entendi perfeitamente.. grato pela sugestão...

--
Flávio H. de Carvalho
Projeto e Desenvolvimento
AmbienteGEO Tecnologia
(35) 3821-6590 / (35) 8874-9222
Lavras - MG

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
Diullei Gomes
Desenvolvedor .NET
http://diullei.com/
http://twitter.com/diullei

[Humberto Marchezi]

Acho que entendi a sua questão.
Pessoalmente, eu sempre trabalho com ORMs, mas nos casos onde eu tinha que fazer uma consulta complexa ao banco-de-dados, eu trabalhava com SQLs que diretamente populavam os DTOs. Essas consultas SQL também eram encapsuladas em um método de algum repositório.

Haviam certos tipos de consultas ao banco onde ficava mais rápido ou até mesmo mais simples de de fazer uma consulta com SQL do que com NHibenate-Linq. 
Mesmo que o ORM seja otimizado para gerar consultas ele não consegue saber exatamente o que vc esta querendo em alguns casos daí o uso do SQL, caso realmente necessário.
Mas nós sempre tentávamos dar preferência ao Linq pois as consultas são refatoráveis.

Olha teve uma thread sobre essa questão na lista de DDD do yahoo infelizmente não me lembro do link dessa thread.

[Diullei Gomes]

Acho que a otimização prematura nesse caso deve ser evitada. Meu conselho é: Utilize ORM depois utilize uma ferramenta de profile (caso esteja utilizando o NHibernate poderia ser o NHprof http://nhprof.com/), execute testes em diversos cenários nos quais a sua consulta em questão esteja sendo utilizada. Se estiver utilizando Nhibernate juntamente com o NHprof ele irá te dar dicas de como otimizar sua consulta caso encontre "warns". Isso é muito util... Se ainda assim depois disso tudo o tempo de resposta de sua consulta não estiver satisfazendo as necessidades de tempo de resposta pré estabelecidas, aí sim vc otimiza este ponto de outra forma, e nesse caso escrever ADO.NET na mão pode ou não ser uma solução.

Acho o ponto de partida para otimizar consultas deve surgir de uma especificação de tempo de resposta para a mesma. Não tem importância eu elevar ao extremo a velocidade de uma consulta que não dependa de um alto tempo de resposta, e se a infraestrutura do meu projeto está toda utilizando ORM eu só vou utilizar meu tempo escrevendo ADO.NET ou utilizando soluções de cache ou seja lá o que for... se isso for necessário para atender a minha especificação.

2010/8/31 Humberto Marchezi <hcmar...@gmail.com>

--

[Flávio Henrique de Carvalho]

Tuca, este post tem muito haver com um outro que eu havia lançado ontem e por isto quero responder sua pergunta.

A origem de minha dúvida e também do Alessandro sobre a queda de performance no uso de ORM, vem do fato da adição de uma nova camada entre a aplicação e o banco. Pensa comigo senão parece lógico, pensar que a consulta que ia diretamente do framework  para o banco de dados e executava uma instrução, agora passa por uma nova camada (ORM) é interpretada por ela e só depois vai ao banco. Estou sendo simplista demais, eu sei, e não sei como funciona a codificação interna destas arquiteturas. Mas parece claro demais pra mim, que quanto mais camadas adicionamos ao nosso sistema, ganhamos em manutenção e organização, mas perdemos na comunicação entre elas (performance).

Flávio
http://flaviohenriquedecarvalho.spaces.live.com/

Em 31 de agosto de 2010 10:20, Alessandro de Souza <alessandr...@gmail.com> escreveu:

Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO, para levar os dados dos objetos de consulta até a interface gráfica. De fato devo popular uma lista com estes DTO´s.

E pelo que entedi, não há ganho de performance em deixar de usar um ORM.

Eu só queria ouvir alguém que já teve experiência com este tipo de situação. Apesar de que todo sistema precisa de consulta né...  problema é que quem usa DDD as vezes retorna dos repositórios uma lista das entidades, ai sim é um erro pq consome-se muitos recursos que não serão utilizados, visto que, seria apenas para mostrar os dados.

Ah.. TUCA entendi perfeitamente.. grato pela sugestão...

--

[Vinicius Quaiato]

Acho que a menos que você vá trabalhar com DataTable, utilize o ORM (e mesmo assim não sei se o TableAdapter.Fill é mais rápido).

Vinicius Quaiato
http://viniciusquaiato.com

Twitter
vinicius...@gmail.com vinicius...@gmail.com

2010/8/31 Diullei Gomes <diu...@gmail.com>

[tucaz]

Pessoal,

vou responder tudo em partes. Vamos lá:

1) Acho que o cenário deste teste que foi apresentado não representa
uma amostra fiel do que uma aplicação faz, afinal não executamos 1000x
a mesma consulta. Se esse fosse o caso, NHibernate ganharia de alguns
milhões a zero, pois com ADO você iria 1000x no DB enquanto com NH
usando cache nivel 1 (que é padrão) você iria uma vez só.

2) Em outros cenários onde as consultas são mais hetereogênas, ADO
nativo deve ganhar por pouco, mas só se você escrever suas rotinas de
hidratação de maneira 100% perfeita, pois o NH utiliza reflection pra
efetuar a hidratação das entidades e isso vai dar um impacto em
performance com certeza.

3) Em uma aplicação OLTP geralmente NH deve ganhar justamente pelo uso
do cache nivel um e dar um show caso você habilite cache nivel dois.
Ele ganha porque vai manter diversos objetos pré carregados enquanto
com ADO nativo você teria que efetuar o controle de maneira manual
além de possuir diversas estratégias de fetch prontas e otimizadas.

4) Em todo caso, você não precisa usar sempre LINQ ou consultas usando
traversing. Um ORM é muito mais. Além do LINQ, vc tem HQL que consegue
gerar qualquer query e te devolver objetos anonimos/DTOs e também as
projections pra operar sobre grupos e aggregates que também te devolve
objetos anonimos/DTOs. Pra finalizar, pra consultas dinamicas e
tipadas vc ainda tem Criteria que é ninja.

5) Por ultimo, em uma aplicação onde leituras são intensas você tem
dois cenários: a) Uso de cache no front end (IIS no caso de uma
aplicação web) então tanto faz o jeito que vc efetua a consulta, pois
o HTML final vai ficar armazenado e b) Construir uma aplicação voltada
pra relatórios com a tecnologia adequada e ai não seria o caso de um
ORM, mas sim outras ferramentas também diferentes do ADO nativo.

Em qualquer cenário, por mais que exista algum impacto de performance
(e ele existe) este impacto não vai ser seu gargalo e se for, seria o
mesmo que se você usasse ADO nativo, portanto não faz sentido escrever
DAO na mão. O benefício de usar um ORM (decente) supera todos os
drawbacks.

Vou tentar fazer um benchmark e um post com algumas considerações a
respeito.

Att.,
Tuca

On Aug 31, 11:57 am, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Acho que a menos que você vá trabalhar com DataTable, utilize o ORM (e mesmo
> assim não sei se o TableAdapter.Fill é mais rápido).
>

> *Vinicius Quaiato*http://viniciusquaiato.com
>
> <vquaiato> Twitter <vquaiato>
> [image: Google Talk/] vinicius.quai...@gmail.com [image: MSN/]
> vinicius.quai...@gmail.com
>
> 2010/8/31 Diullei Gomes <diul...@gmail.com>

>
>
>
> > Acho que a otimização prematura nesse caso deve ser evitada. Meu conselho
> > é: Utilize ORM depois utilize uma ferramenta de profile (caso esteja

> > utilizando o NHibernate poderia ser o NHprofhttp://nhprof.com/), execute

> > testes em diversos cenários nos quais a sua consulta em questão esteja sendo
> > utilizada. Se estiver utilizando Nhibernate juntamente com o NHprof ele irá
> > te dar dicas de como otimizar sua consulta caso encontre "warns". Isso é
> > muito util... Se ainda assim depois disso tudo o tempo de resposta de sua
> > consulta não estiver satisfazendo as necessidades de tempo de resposta pré
> > estabelecidas, aí sim vc otimiza este ponto de outra forma, e nesse caso
> > escrever ADO.NET na mão pode ou não ser uma solução.
>
> > Acho o ponto de partida para otimizar consultas deve surgir de uma
> > especificação de tempo de resposta para a mesma. Não tem importância eu
> > elevar ao extremo a velocidade de uma consulta que não dependa de um alto
> > tempo de resposta, e se a infraestrutura do meu projeto está toda utilizando
> > ORM eu só vou utilizar meu tempo escrevendo ADO.NET ou utilizando soluções
> > de cache ou seja lá o que for... se isso for necessário para atender a minha
> > especificação.
>

> > 2010/8/31 Humberto Marchezi <hcmarch...@gmail.com>

>
> > Acho que entendi a sua questão.
> >> Pessoalmente, eu sempre trabalho com ORMs, mas nos casos onde eu tinha que
> >> fazer uma consulta complexa ao banco-de-dados, eu trabalhava com SQLs que
> >> diretamente populavam os DTOs. Essas consultas SQL também eram encapsuladas
> >> em um método de algum repositório.
>
> >> Haviam certos tipos de consultas ao banco onde ficava mais rápido ou até
> >> mesmo mais simples de de fazer uma consulta com SQL do que com
> >> NHibenate-Linq.
> >> Mesmo que o ORM seja otimizado para gerar consultas ele não consegue saber
> >> exatamente o que vc esta querendo em alguns casos daí o uso do SQL, caso
> >> realmente necessário.
> >> Mas nós sempre tentávamos dar preferência ao Linq pois as consultas são
> >> refatoráveis.
>
> >> Olha teve uma thread sobre essa questão na lista de DDD do yahoo
> >> infelizmente não me lembro do link dessa thread.
>

> >> 2010/8/31 Alessandro de Souza <alessandro.de.so...@gmail.com>

>
> >>> Perfeito Humberto.
> >>> A questão é que eu tendo um DTO definido, fica mais fácil (documentado)
> >>> exatamente o que será retornado pelo meu objeto de consulta (quais campos).
> >>> Mais sei também que se eu fizer um 'select new objeto...' ele popula uma
> >>> lista com os DTO´s.
>
> >>> []´s
>

> >>> Em 31 de agosto de 2010 10:31, Humberto Marchezi <hcmarch...@gmail.com>escreveu:
>
> >>>> Mesmo que se queira retornar dados ao invés de uma lista de entidades,
> >>>> um bom ORM como o NHibernate pode fazer isso para você.
>

> >>>> *Ex:*

>
> >>>> ( from c in Repositorio<Cliente>().Query() // Retorna um
> >>>> IQueryable<Cliente>
> >>>>   where c.DataNascimento = XXXXXX && c.Nome like XXXXXX
> >>>>   select c.Nome, c.Endereco, c.Estado.Descricao, .... )   // Essa
> >>>> consulta retorna apenas os dados necessários
>
> >>>> Obs: Nos bastidores, o NHibernate-Linq vai gerar o SQL correspondente a
> >>>> consulta acima.
>

> >>>> 2010/8/31 Alessandro de Souza <alessandro.de.so...@gmail.com>

>
> >>>>>  Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO,
> >>>>> para levar os dados dos objetos de consulta até a interface gráfica. De fato
> >>>>> devo popular uma lista com estes DTO´s.
>
> >>>>> E pelo que entedi, não há ganho de performance em deixar de usar um
> >>>>> ORM.
>
> >>>>> Eu só queria ouvir alguém que já teve experiência com este tipo de
> >>>>> situação. Apesar de que todo sistema precisa de consulta né...  problema é
> >>>>> que quem usa DDD as vezes retorna dos repositórios uma lista das entidades,
> >>>>> ai sim é um erro pq consome-se muitos recursos que não serão utilizados,
> >>>>> visto que, seria apenas para mostrar os dados.
>
> >>>>> Ah.. TUCA entendi perfeitamente.. grato pela sugestão...
>
> >>>>> []´s
>

> >>>>> Em 31 de agosto de 2010 10:17, Cassiano Kuss <cassianok...@gmail.com>escreveu:
>
> >>>>> Talvez a colocação do Alessandro seja executar as querys e simplesmente
> >>>>>> mostrar os dados retornados sem gerar objetos.
>

> >>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>>>> Para mais opções visite o grupo em
> >>>>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>>>>  --
> >>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>>> hospedado no Google Groups.
> >>>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>>>> Para sair do grupo envie uma mensagem para

> >>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>>> Para mais opções visite o grupo em
> >>>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>>>  --
> >>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>> hospedado no Google Groups.
> >>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>>> Para sair do grupo envie uma mensagem para

> >>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>> Para mais opções visite o grupo em
> >>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>> --
> >>>> Humberto C Marchezi
> >>>> ---------------------------------------------------------
>
> >>>> --
> >>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>> hospedado no Google Groups.
> >>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>> Para sair do grupo envie uma mensagem para

> >>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>> Para mais opções visite o grupo em
> >>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>  --
> >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> hospedado no Google Groups.
> >>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>> Para sair do grupo envie uma mensagem para

> >>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>> Para mais opções visite o grupo em
> >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >> --
> >> Humberto C Marchezi
> >> ---------------------------------------------------------
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Diullei Gomes
> > Desenvolvedor .NET
> >http://diullei.com/
> >http://twitter.com/diullei
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

[tucaz]

Po...dei mó resposta grande e acho que não foi :(

Receberam?

On Aug 31, 11:57 am, Vinicius Quaiato <vinicius.quai...@gmail.com>
wrote:

> Acho que a menos que você vá trabalhar com DataTable, utilize o ORM (e mesmo
> assim não sei se o TableAdapter.Fill é mais rápido).
>

> *Vinicius Quaiato*http://viniciusquaiato.com
>
> <vquaiato> Twitter <vquaiato>
> [image: Google Talk/] vinicius.quai...@gmail.com [image: MSN/]
> vinicius.quai...@gmail.com
>
> 2010/8/31 Diullei Gomes <diul...@gmail.com>
>
>
>

> > Acho que a otimização prematura nesse caso deve ser evitada. Meu conselho
> > é: Utilize ORM depois utilize uma ferramenta de profile (caso esteja

> > utilizando o NHibernate poderia ser o NHprofhttp://nhprof.com/), execute

> > testes em diversos cenários nos quais a sua consulta em questão esteja sendo
> > utilizada. Se estiver utilizando Nhibernate juntamente com o NHprof ele irá
> > te dar dicas de como otimizar sua consulta caso encontre "warns". Isso é
> > muito util... Se ainda assim depois disso tudo o tempo de resposta de sua
> > consulta não estiver satisfazendo as necessidades de tempo de resposta pré
> > estabelecidas, aí sim vc otimiza este ponto de outra forma, e nesse caso
> > escrever ADO.NET na mão pode ou não ser uma solução.
>
> > Acho o ponto de partida para otimizar consultas deve surgir de uma
> > especificação de tempo de resposta para a mesma. Não tem importância eu
> > elevar ao extremo a velocidade de uma consulta que não dependa de um alto
> > tempo de resposta, e se a infraestrutura do meu projeto está toda utilizando
> > ORM eu só vou utilizar meu tempo escrevendo ADO.NET ou utilizando soluções
> > de cache ou seja lá o que for... se isso for necessário para atender a minha
> > especificação.
>

> > 2010/8/31 Humberto Marchezi <hcmarch...@gmail.com>

>
> > Acho que entendi a sua questão.
> >> Pessoalmente, eu sempre trabalho com ORMs, mas nos casos onde eu tinha que
> >> fazer uma consulta complexa ao banco-de-dados, eu trabalhava com SQLs que
> >> diretamente populavam os DTOs. Essas consultas SQL também eram encapsuladas
> >> em um método de algum repositório.
>
> >> Haviam certos tipos de consultas ao banco onde ficava mais rápido ou até
> >> mesmo mais simples de de fazer uma consulta com SQL do que com
> >> NHibenate-Linq.
> >> Mesmo que o ORM seja otimizado para gerar consultas ele não consegue saber
> >> exatamente o que vc esta querendo em alguns casos daí o uso do SQL, caso
> >> realmente necessário.
> >> Mas nós sempre tentávamos dar preferência ao Linq pois as consultas são
> >> refatoráveis.
>
> >> Olha teve uma thread sobre essa questão na lista de DDD do yahoo
> >> infelizmente não me lembro do link dessa thread.
>

> >> 2010/8/31 Alessandro de Souza <alessandro.de.so...@gmail.com>

>
> >>> Perfeito Humberto.
> >>> A questão é que eu tendo um DTO definido, fica mais fácil (documentado)
> >>> exatamente o que será retornado pelo meu objeto de consulta (quais campos).
> >>> Mais sei também que se eu fizer um 'select new objeto...' ele popula uma
> >>> lista com os DTO´s.
>
> >>> []´s
>

> >>> Em 31 de agosto de 2010 10:31, Humberto Marchezi <hcmarch...@gmail.com>escreveu:
>
> >>>> Mesmo que se queira retornar dados ao invés de uma lista de entidades,
> >>>> um bom ORM como o NHibernate pode fazer isso para você.
>

> >>>> *Ex:*

>
> >>>> ( from c in Repositorio<Cliente>().Query() // Retorna um
> >>>> IQueryable<Cliente>
> >>>>   where c.DataNascimento = XXXXXX && c.Nome like XXXXXX
> >>>>   select c.Nome, c.Endereco, c.Estado.Descricao, .... )   // Essa
> >>>> consulta retorna apenas os dados necessários
>
> >>>> Obs: Nos bastidores, o NHibernate-Linq vai gerar o SQL correspondente a
> >>>> consulta acima.
>

> >>>> 2010/8/31 Alessandro de Souza <alessandro.de.so...@gmail.com>

>
> >>>>>  Cassiano, acho que o TUCA entendeu bem. Na verdade preciso de um DTO,
> >>>>> para levar os dados dos objetos de consulta até a interface gráfica. De fato
> >>>>> devo popular uma lista com estes DTO´s.
>
> >>>>> E pelo que entedi, não há ganho de performance em deixar de usar um
> >>>>> ORM.
>
> >>>>> Eu só queria ouvir alguém que já teve experiência com este tipo de
> >>>>> situação. Apesar de que todo sistema precisa de consulta né...  problema é
> >>>>> que quem usa DDD as vezes retorna dos repositórios uma lista das entidades,
> >>>>> ai sim é um erro pq consome-se muitos recursos que não serão utilizados,
> >>>>> visto que, seria apenas para mostrar os dados.
>
> >>>>> Ah.. TUCA entendi perfeitamente.. grato pela sugestão...
>
> >>>>> []´s
>

> >>>>> Em 31 de agosto de 2010 10:17, Cassiano Kuss <cassianok...@gmail.com>escreveu:
>
> >>>>> Talvez a colocação do Alessandro seja executar as querys e simplesmente
> >>>>>> mostrar os dados retornados sem gerar objetos.
>

> >>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>>>> Para mais opções visite o grupo em
> >>>>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>>>>  --
> >>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>>> hospedado no Google Groups.
> >>>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>>>> Para sair do grupo envie uma mensagem para

> >>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>>> Para mais opções visite o grupo em
> >>>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>>>  --
> >>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>> hospedado no Google Groups.
> >>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>>> Para sair do grupo envie uma mensagem para

> >>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>>> Para mais opções visite o grupo em
> >>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>> --
> >>>> Humberto C Marchezi
> >>>> ---------------------------------------------------------
>
> >>>> --
> >>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>> hospedado no Google Groups.
> >>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>>> Para sair do grupo envie uma mensagem para

> >>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>>> Para mais opções visite o grupo em
> >>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>>  --
> >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> hospedado no Google Groups.
> >>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>> Para sair do grupo envie uma mensagem para

> >>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >>> Para mais opções visite o grupo em
> >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >> --
> >> Humberto C Marchezi
> >> ---------------------------------------------------------
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Diullei Gomes
> > Desenvolvedor .NET
> >http://diullei.com/
> >http://twitter.com/diullei
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

[Bruno D'Alessio]

Sim tucaz, to lendo ela agora!

Bruno D'Alessio
Arquiteto de Software

[Diullei Gomes]

Eu recebi! rs

2010/8/31 tucaz <tuc...@gmail.com>

[Alessandro de Souza]

Eu tb...

valeu  ;-)

[Cadu]

tucaz e teu curso cara !!?!?!

Eu tb recebi :)

Em 31 de agosto de 2010 09:20, Alessandro de Souza
<alessandr...@gmail.com> escreveu:

--
Twitter: @cadu_sza
Blog: http://architecturelife.wordpress.com/

[Diogo Miranda]

Eu ia fazer a mesma pergunta... depois de tantos argumentos, a única
que falta é sair esse curso.
Manda ver Tucaz!

--
Diogo A. Miranda
Analista de Sistemas GIS.NET
MHR Processamento de Dados
+55 11 7617-5503

[tucaz]

O curso não morreu. A primeira turma aberta está de rosca por conta de
lugar/infra estrutura, mas semana que vem vou fazer a primeira turma
InCompany já :)

Ainda não divulguei mais nada porque ainda não consegui fechar esta
ultima parte, mas vai sair!

Att.,
Tuca

On Aug 31, 1:54 pm, Diogo Miranda <dmst...@gmail.com> wrote:
> Eu ia fazer a mesma pergunta... depois de tantos argumentos, a única
> que falta é sair esse curso.
> Manda ver Tucaz!
>

> Em 31 de agosto de 2010 13:31, Cadu <cadus...@gmail.com> escreveu:
>
>
>
> > tucaz e teu curso cara !!?!?!
>
> > Eu tb recebi :)
>
> > Em 31 de agosto de 2010 09:20, Alessandro de Souza

> > <alessandro.de.so...@gmail.com> escreveu:
> >> Eu tb...
> >> valeu  ;-)

>
> >> Em 31 de agosto de 2010 12:46, Diullei Gomes <diul...@gmail.com> escreveu:
>
> >>> Eu recebi! rs
>

> >>> 2010/8/31 tucaz <tuca...@gmail.com>

> ...
>
> read more »

[Flávio Henrique de Carvalho]

É um curso de que ? NHibernate ?

[Stupied4ever]

@tucaz ,

Eu concordo com você, as pessoas não podem deixar de usar ORM por
performance, não sei qual o custo real, sei que não é zero mas tbm sei
que o custo beneficio é muito bacana.

Eu gostaria sim de um benchmark confiavel, quando voce fizer manda no
grupo.

[]'s


On 31 ago, 14:04, Flávio Henrique de Carvalho

<flaviohenriquedecarva...@gmail.com> wrote:
> É um curso de que ? NHibernate ?
>

> > > >>>> > >>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
>
> ...
>
> mais »

[Marcus Alexandre Silva]

Depende da aplicação.
Na maioria das vezes o Orm compensa.

[Cássio Rogério Eskelsen]

"Peraí"... a variável performance não pode ser desconsiderada só pq  com ORM é mais prático desenvolver...

Cássio Rogério Eskelsen

2010/8/31 Stupied4ever <stupie...@gmail.com>

[Marcus Alexandre Silva]

2 Round....
E la vamos nós mais uma vez....

Em 31 de agosto de 2010 16:35, Cássio Rogério Eskelsen
<eske...@gmail.com> escreveu:

[Alessandro de Souza]

rsrsrsrs.... nossa...  os caras aqui na empresa acharam que eu estava ficando louco, começei a rir sozinho.. hehehe...

[Cássio Rogério Eskelsen]

Vou até uma 10a. vez se for o caso, pq considero absurdo desconsiderar a performance. Isso é desrespeito com o cliente/usuário.

Cássio Rogério Eskelsen

2010/8/31 Marcus Alexandre Silva <inf.marcu...@gmail.com>

[Ellison Alves]

@Cássio

"a variável performance não pode ser desconsiderada só pq  com ORM é mais prático desenvolver..."

Eu digo que depende... performance é um requisito funcional da aplicação ?

As vezes podemos pecar mto em querer desenvolver algo super, hiper, mega, galático e no final...pode acontecer...de vc ver que seu esforço foi pra dar um click que insere um registro no banco....rsrsrsrsrs

Isso é absolutamente normal, o importante é procurar ser imparcial e ver o que realmente é necessário...

Exemplo...todo carro precisa de seguro ?

todo sistema de informação exige segurança de informação.

Eu diria mais, acredito que com essa onda do Agile ganhando força faça com que o desenvolvimento de software seja rápido a um ponto de tornar isso um requisito funcional da aplicação....

Bem...apenas uma opinião..

Abraço!

Em 31 de agosto de 2010 16:35, Cássio Rogério Eskelsen <eske...@gmail.com> escreveu:

--
Ellison Alves de Souza

[Ellison Alves]

Bah...escrevi errado...quando falo de requisito funcional...estava pensando em requisitos não-funcionais

[José Filipe Néis]

Além da questão da lógica de hidratação perfeita dos objetos, a utilização de Stateless Sessions ao invés de Statefull, por exemplo, também influenciaria certamente.

 

Perde o benefício do cachê nível 1 citado pelo @tucaz, mas pra operações de batch mata a pau!

 

Abçs.

 

Zé Filipe

[Daniel Moreira Yokoyama]

Em 31 de agosto de 2010 16:47, Cássio Rogério Eskelsen <eske...@gmail.com> escreveu:

Vou até uma 10a. vez se for o caso, pq considero absurdo desconsiderar a performance. Isso é desrespeito com o cliente/usuário.

 

Lembro de alguém citar a frase: Otimização precoce é a raiz de todo o mal.

 

Normalmente por que a pessoa se concentra muito em performizar o acesso ao banco de dados (onde a queda na performance é menos expressiva) e ferra com a escalabilidade.

 

Vamos a primeira lição de performance: Software Rápido é diferente de Software Escalável.

 

Ele pode ser rápido na hora de testar... mas na hora de homologar, quando 3 usuários entrarem, já pode não ser tão rápido. E quando entrar em produção, 100 usuários acessando, ele vai demonstrar ser uma droga.

 

O que se perde de perfomance hoje com o ORM, no que diz respeito a "Acesso a Dados" passa despercebido pelo usuário, desde que você trate bem a escalabilidade do seu software onde realmente importa, i.e: pontos de latência, cache, etc, etc, etc.

 

O que se ganha com o ORM é produtividade, o que se perde de performance pode ser ganho em outros pontos já que uma aplicação não é (ou não deveria ser) puro acesso ao banco.

 

Em ambos os casos, se você prioriza performance, a palavra chave é só: Escalabilidade. Se você ignorar esta palavra, por mais performático que seu "código" possa ser, não significa necessariamente que ele vai atender ao requisito performance quando estiver em produção. (independente de você usar ORM ou não).

[Cássio Rogério Eskelsen]

Daniel,

Já tenho uma boa estrada para não cair na besteira de fazer otimização precoce.

Cássio Rogério Eskelsen
 

2010/8/31 Daniel Moreira Yokoyama <moreira....@gmail.com>

[JR]

@Tucaz

Concordo com voce. O uso "correto" do NHibernate traz mais benefícios
do que problemas.

A questão da performance deve ser considerada em casos isolados.
O que não podemos é ficar discutindo uma diferença de performance = a
raiz quadrada de um cabelo de sapo sobre 2.

[]s

[tucaz]

Publiquei um post sobre o assunto com uma comparação ->
http://blog.tucaz.net/2010/08/31/performance-nhibernate-versus-ado-net/

Enjoy!

Att.,
Tuca

[Fabio Margarito]

Muito bacana o Post.. parabéns.

[Luiz Augusto Moreira Costa]

Oi,

Não sei se todos podem concordar com o Greg Young, mas ele diz que o modelo de Objetos não é o melhor modelo para leitura. 

Esta afirmação é um pouco forte, mas se pensarmos bem, nem todas as necessidades de consulta são resolvidas facilmente com ORM.

Baseado nisso, ele propõe uma arquitetura em que é separado Leitura e Escrita, conhecida como CQRS.

No meu projeto atual, utilizamos CQRS em conjunto com Event Sourcing. A vantagem é que vc tem uma liberdade muito grande em deixar seu banco de dados o mais otimizado possível para consultas, desnormalizando tabelas, agregando dados, etc, e acessá-lo diretamente para resolver os problemas de consulta.

Em um primeiro instante, isso parece bizarro. Vale lembrar que seu domínio, continua orientado a objetos, e utilizando todos as boas práticas, usando OO no que ele tem de melhor.

Para quem quer entender um pouco mais sobre o assunto:

http://www.udidahan.com/2009/12/09/clarified-cqrs/

Luiz Costa

2010/8/31 Fabio Margarito <fabioma...@gmail.com>

[tucaz]

Perfeito Luis!

Se vc precisa de muitas consultas em um formato diferente do seu
modelo OO e/ou de dados o ideal é usar uma outra ferramenta e esse
modelo de CQRS cai perfeitamente.

On Aug 31, 11:01 pm, Luiz Augusto Moreira Costa <gutomco...@gmail.com>
wrote:

> Oi,
>
> Não sei se todos podem concordar com o Greg

> Young<http://skillsmatter.com/podcast/design-architecture/architectural-inn...>,

> mas ele diz que o modelo de Objetos não é o melhor modelo para leitura.
> Esta afirmação é um pouco forte, mas se pensarmos bem, nem todas as

> necessidades de consulta são resolvidas *facilmente* com ORM.

> Baseado nisso, ele propõe uma arquitetura em que é separado Leitura e
> Escrita, conhecida como CQRS.
> No meu projeto atual, utilizamos CQRS em conjunto com Event

> Sourcing<http://martinfowler.com/eaaDev/EventSourcing.html>.

> A vantagem é que vc tem uma liberdade muito grande em deixar seu banco de
> dados o mais otimizado possível para consultas, desnormalizando tabelas,
> agregando dados, etc, e acessá-lo diretamente para resolver os problemas de
> consulta.
> Em um primeiro instante, isso parece bizarro. Vale lembrar que seu domínio,
> continua orientado a objetos, e utilizando todos as boas práticas, usando OO
> no que ele tem de melhor.
>
> Para quem quer entender um pouco mais sobre o assunto:http://www.udidahan.com/2009/12/09/clarified-cqrs/
>
> Luiz Costa
>

> 2010/8/31 Fabio Margarito <fabiomargar...@gmail.com>

>
>
>
> > Muito bacana o Post.. parabéns.
>

> > Em 31 de agosto de 2010 22:29, tucaz <tuca...@gmail.com> escreveu:
>
> > Publiquei um post sobre o assunto com uma comparação ->
> >>http://blog.tucaz.net/2010/08/31/performance-nhibernate-versus-ado-net/
>
> >> Enjoy!
>
> >> Att.,
> >> Tuca
>
> >> On Aug 31, 8:10 pm, JR <agcjun...@gmail.com> wrote:
> >> > @Tucaz
>
> >> > Concordo com voce. O uso "correto" do NHibernate traz mais benefícios
> >> > do que problemas.
>
> >> > A questão da performance deve ser considerada em casos isolados.
> >> > O que não podemos é ficar discutindo uma diferença de performance = a
> >> > raiz quadrada de um cabelo de sapo sobre 2.
>
> >> > []s
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >> Para sair do grupo envie uma mensagem para

> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >  --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

[edmilson hora]

Caraca,     Agora  tem que colocar  os dados  em dois bancos   um   Um  Otimizado para  Leitura  e Outro Otimizado para escrita.     No começo vendem a  idéia que de o desenvolvimento  vai ser  mais  facil  e blá, blá, blá.  Depois  a coisa começa a tomar  caminhos  cada vez  mais  estranhos...   Vejam este Artigo --- Em ter, 31/8/10, Luiz Augusto Moreira Costa <gutom...@gmail.com> escreveu:

De: Luiz Augusto Moreira Costa <gutom...@gmail.com> Assunto: Re: [dotnetarchitects] Re: DDD - Objetos de consulta usando ORM - o que vcs acham?

[Cássio Rogério Eskelsen]

Isso é mais comum do que você imagina.

Em locais onde você precisa de muita pesquisa de dados não vai ter banco relacional que de conta.

Aliás, enfatizando, o problema não está só na OO. O problema vem mais debaixo, lá do banco relacional. 

Em sites onde há muita pesquisa, principalmente textual, é comum indexar os dados em uma base a parte, sendo que essa normalmente é uma base Lucene (ou algo semelhante). Alguns exemplos de sites que fazem isso: zappos.com (maior site de calçados nos EUA, q agora é da Amazon), Apontador.com.br e Guiamais.com.br

Cássio Rogério Eskelsen  

2010/9/1 edmilson hora <edmils...@yahoo.com.br>

[Flávio Henrique de Carvalho]

Pessoal, quero adicionar mais um ponto de vista sobre o que foi falado nesta thread, escrevi um post para expor o que penso sobre tudo que comentamos e fizemos até agora,
http://flaviohenriquedecarvalho.spaces.live.com/blog/cns!8AFD5610DB04FEEC!284.entry

Boas reflexões.

Flávio
http://flaviohenriquedecarvalho.spaces.live.com/default.aspx

[Juan Lopes]

Flávio, li seu post. Concordo que o uso de um ORM muitas vezes abstrai tanto o banco de dados que algumas pessoas passam a não entender mais como as coisas funcionam. Entretanto, temos que pensar se isso não é um débito técnico ao qual todos estão sujeitos (não entender o funcionamento de um banco de dados é algo que pode vir da teoria) ou se esse reinado dos bancos de dados relacionais ainda é saudável para o mercado, mas esta é outra discussão.

O que eu quero colocar aqui é que um ORM não serve simplesmente para acessar dados no banco. Se você o usa desse jeito, está subestimando a capacidade dele. Um ORM mapeia seu modelo relacional em objetos, suprindo diversas necessidades que o primeiro não tem, como polimorfismo e separação de responsabilidades. Ele permite que você trabalhe com um modelo mais OO, em vez de ter que ficar amarrado às limitações do seu banco de dados. Em segundo lugar, ele implementa diversos mecanismos que você não precisa - nem deve - implementar na mão, como 1st e 2nd level caches (já citados pelo Tuca), query DSLs, specifications, vendor abstraction, etc.

Acredito que muitos aqui também já trabalharam muito com acesso direto no passado e sabem dos benefícios que o controle total trás. Mas não duvide da nossa capacidade de entender os benefícios que uma boa abstração pode proporcionar.

É uma pena que ninguém tenha "convencido" você a usar um ORM. Garanto que é uma boa escolha, principalmente hoje em dia, pelas ferramentas disponíveis no mercado.

2010/9/1 Flávio Henrique de Carvalho <flaviohenriq...@gmail.com>

--
Kind regards,
Juan Lopes

http://qrcode.juanlopes.net

[Luiz Augusto Moreira Costa]

Oi Edmilson,

Vc não precisa ter dois banco de dados. Vc pode até ter um banco só, mas algumas tabelas podem ser desnormalizadas para facilitar consultas.

Em alguns casos, não vale a pena, mas existem casos onde isso pode ser um fator importante. 

Em CQRS não existe banco otimizado para escrita, existe seu banco de dados. Se vc usar Event Sourcing, vc pode ter por exemplo 2 tabelas para gravar todos os comandos e eventos que aconteceram na sua aplicação e outras tabelas que serão próprias para leitura.

Se vc quiser, vc pode até ter isso separado. Mas isso não é mandatório.

Luiz Costa

2010/9/1 edmilson hora <edmils...@yahoo.com.br>