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?
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.
<alessandro.de.so...@gmail.com> wrote:
> 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?
> 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 > <alessandro.de.so...@gmail.com> wrote: > > 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
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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.
> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
> 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 >> <alessandro.de.so...@gmail.com> wrote: >> > 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
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups. >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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.
>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>> 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 >>> <alessandro.de.so...@gmail.com> wrote: >>> > 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
>>> -- >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>> hospedado no Google Groups. >>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@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 ---------------------------------------------------------
@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.
> > Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
> > 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
> >> <alessandro.de.so...@gmail.com> wrote:
> >> > 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
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
> >> Para sair do grupo envie uma mensagem para
> >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> > Para sair do grupo envie uma mensagem para
> > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com>
> > Para mais opções visite o grupo em
> >http://groups.google.com/group/dotnetarchitects?hl=pt-br
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.
>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>>> 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 >>>> <alessandro.de.so...@gmail.com> wrote: >>>> > 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
>>>> -- >>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>> hospedado no Google Groups. >>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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 <flaviohenriquedecarva...@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).
> Em 31 de agosto de 2010 10:20, Alessandro de Souza < > alessandro.de.so...@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...
>> 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.
>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>>> 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 >>>> <alessandro.de.so...@gmail.com> wrote: >>>> > 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
>>>> -- >>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>> hospedado no Google Groups. >>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > 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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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.
>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>>>> 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 >>>>> <alessandro.de.so...@gmail.com> wrote: >>>>> > 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
>>>>> -- >>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>>> hospedado no Google Groups. >>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>>> Para sair do grupo envie uma mensagem para >>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@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 ---------------------------------------------------------
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.
> 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.
>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>>>>> 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 >>>>>> <alessandro.de.so...@gmail.com> wrote: >>>>>> > 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
>>>>>> -- >>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>>>> hospedado no Google Groups. >>>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>>>> Para sair do grupo envie uma mensagem para >>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>>> Para sair do grupo envie uma mensagem para >>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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).
> 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...
> 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.
>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>> 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 >>> <alessandro.de.so...@gmail.com> wrote: >>> > 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
>>> -- >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>> hospedado no Google Groups. >>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- Flávio H. de Carvalho Projeto e Desenvolvimento AmbienteGEO Tecnologia (35) 3821-6590 / (35) 8874-9222 Lavras - MG
> 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.
> 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.
>>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
>>>>>> 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 >>>>>>> <alessandro.de.so...@gmail.com> wrote: >>>>>>> > 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
>>>>>>> -- >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>>>>> hospedado no Google Groups. >>>>>>> Para postar envie uma mensagem para >>>>>>> dotnetarchitects@googlegroups.com >>>>>>> Para sair do grupo envie uma mensagem para >>>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>>>> Para sair do grupo envie uma mensagem para >>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>>> Para sair do grupo envie uma mensagem para >>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
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 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.
> > 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.
> >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
> >>>>>> 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
> >>>>>>> <alessandro.de.so...@gmail.com> wrote:
> >>>>>>> > 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
> >>>>>>> --
> >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>>>> hospedado no Google Groups.
> >>>>>>> Para postar envie uma mensagem para
> >>>>>>> dotnetarchitects@googlegroups.com
> >>>>>>> Para sair do grupo envie uma mensagem para
> >>>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >>>>>> Para sair do grupo envie uma mensagem para
> >>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com>
> >>>>>> Para mais opções visite o grupo em
> >>>>>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
> > 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.
> > 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.
> >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> escreveu:
> >>>>>> 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
> >>>>>>> <alessandro.de.so...@gmail.com> wrote:
> >>>>>>> > 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
> >>>>>>> --
> >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>>>>>> hospedado no Google Groups.
> >>>>>>> Para postar envie uma mensagem para
> >>>>>>> dotnetarchitects@googlegroups.com
> >>>>>>> Para sair do grupo envie uma mensagem para
> >>>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >>>>>> Para sair do grupo envie uma mensagem para
> >>>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >>>>> Para sair do grupo envie uma mensagem para
> >>>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >>>> Para sair do grupo envie uma mensagem para
> >>>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >>> Para sair do grupo envie uma mensagem para
> >>> dotnetarchitects+unsubscribe@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 dotnetarchitects@googlegroups.com
> >> Para sair do grupo envie uma mensagem para
> >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com>
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
> 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).
> > > 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 <http://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 <http://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.
> > > 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.
> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> > escreveu:
> > >>>>>> 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 > > >>>>>>> <alessandro.de.so...@gmail.com> wrote: > > >>>>>>> > 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<http://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
> > >>>>>>> -- > > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net > Architects > > >>>>>>> hospedado no Google Groups. > > >>>>>>> Para postar envie uma mensagem para > > >>>>>>> dotnetarchitects@googlegroups.com > > >>>>>>> Para sair do grupo envie uma mensagem para > > >>>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>>>> Para sair do grupo envie uma mensagem para > > >>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>>> Para sair do grupo envie uma mensagem para > > >>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>> Para sair do grupo envie uma mensagem para > > >>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>> Para sair do grupo envie uma mensagem para > > >>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com><dotnetarchitects%2Bunsubscrib > e@googlegroups.com> > > >>> Para mais opções visite o grupo em > > >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
> 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).
> > > 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.
> > > 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.
> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> > escreveu:
> > >>>>>> 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 > > >>>>>>> <alessandro.de.so...@gmail.com> wrote: > > >>>>>>> > 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
> > >>>>>>> -- > > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net > Architects > > >>>>>>> hospedado no Google Groups. > > >>>>>>> Para postar envie uma mensagem para > > >>>>>>> dotnetarchitects@googlegroups.com > > >>>>>>> Para sair do grupo envie uma mensagem para > > >>>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>>>> Para sair do grupo envie uma mensagem para > > >>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>>> Para sair do grupo envie uma mensagem para > > >>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>>> Para sair do grupo envie uma mensagem para > > >>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 > dotnetarchitects@googlegroups.com > > >>> Para sair do grupo envie uma mensagem para > > >>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com><dotnetarchitects%2Bunsubscrib > e@googlegroups.com> > > >>> Para mais opções visite o grupo em > > >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
> 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).
>> > > 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.
>> > > 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.
>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> >> escreveu:
>> > >>>>>> 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 >> > >>>>>>> <alessandro.de.so...@gmail.com> wrote: >> > >>>>>>> > 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
>> > >>>>>>> -- >> > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net >> Architects >> > >>>>>>> hospedado no Google Groups. >> > >>>>>>> Para postar envie uma mensagem para >> > >>>>>>> dotnetarchitects@googlegroups.com >> > >>>>>>> Para sair do grupo envie uma mensagem para >> > >>>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 >> dotnetarchitects@googlegroups.com >> > >>>>>> Para sair do grupo envie uma mensagem para >> > >>>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 >> dotnetarchitects@googlegroups.com >> > >>>>> Para sair do grupo envie uma mensagem para >> > >>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 >> dotnetarchitects@googlegroups.com >> > >>>> Para sair do grupo envie uma mensagem para >> > >>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@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 >> dotnetarchitects@googlegroups.com >> > >>> Para sair do grupo envie uma mensagem para
>>> 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).
>>> > > 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.
>>> > > 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.
>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> >>> > >>>>>> escreveu:
>>> > >>>>>> 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 >>> > >>>>>>> <alessandro.de.so...@gmail.com> wrote: >>> > >>>>>>> > 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
>>> > >>>>>>> -- >>> > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net >>> > >>>>>>> Architects >>> > >>>>>>> hospedado no Google Groups. >>> > >>>>>>> Para postar envie uma mensagem para >>> > >>>>>>> dotnetarchitects@googlegroups.com >>> > >>>>>>> Para sair do grupo envie uma mensagem para
>>> > >>>>>>> dotnetarchitects+unsubscribe@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 >>> > >>>>>> dotnetarchitects@googlegroups.com >>> > >>>>>> Para sair do grupo envie uma mensagem para
>>> > >>>>>> dotnetarchitects+unsubscribe@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 >>> > >>>>> dotnetarchitects@googlegroups.com >>> > >>>>> Para sair do grupo envie uma mensagem para
>>> > >>>>> dotnetarchitects+unsubscribe@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
>>>> 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).
>>>> > > 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.
>>>> > > 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.
>>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> >>>> > >>>>>> escreveu:
>>>> > >>>>>> 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 >>>> > >>>>>>> <alessandro.de.so...@gmail.com> wrote: >>>> > >>>>>>> > 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
>>>> > >>>>>>> -- >>>> > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net >>>> > >>>>>>> Architects >>>> > >>>>>>> hospedado no Google Groups. >>>> > >>>>>>> Para postar envie uma mensagem para >>>> > >>>>>>> dotnetarchitects@googlegroups.com >>>> > >>>>>>> Para sair do grupo envie uma mensagem para
>>>> > >>>>>>> dotnetarchitects+unsubscribe@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 >>>> > >>>>>> dotnetarchitects@googlegroups.com >>>> > >>>>>> Para sair do grupo envie uma mensagem para
>>>> > >>>>>> dotnetarchitects+unsubscribe@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 >>>> > >>>>> dotnetarchitects@googlegroups.com >>>> > >>>>> Para sair do grupo envie uma mensagem para
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:
> >>>> 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).
> >>>> > > 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.
> >>>> > > 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.
> >>>> > >>>>> 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.
> >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com>
> >>>> > >>>>>> escreveu:
> >>>> > >>>>>> 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
> >>>> > >>>>>>> <alessandro.de.so...@gmail.com> wrote:
> >>>> > >>>>>>> > 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?
> >>>> > >>>>>>> --
> >>>> > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
> >>>> > >>>>>>> Architects
> >>>> > >>>>>>> hospedado no Google Groups.
> >>>> > >>>>>>> Para postar envie uma mensagem para
> >>>> > >>>>>>> dotnetarchitects@googlegroups.com
> >>>> > >>>>>>> Para sair do grupo envie uma mensagem para
> >>>> > >>>>>>> dotnetarchitects+unsubscribe@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
> >>>> > >>>>>> dotnetarchitects@googlegroups.com
> 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:
> > >>>> 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).
> > >>>> > > 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.
> > >>>> > > 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.
> > >>>> > >>>>> 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.
> > >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> > > >>>> > >>>>>> escreveu:
> > >>>> > >>>>>> 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 > > >>>> > >>>>>>> <alessandro.de.so...@gmail.com> wrote: > > >>>> > >>>>>>> > 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.NETdireto > > >>>> > >>>>>>> > 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?
> > >>>> > >>>>>>> -- > > >>>> > >>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net > > >>>> > >>>>>>> Architects > > >>>> > >>>>>>> hospedado no Google Groups. > > >>>> > >>>>>>> Para postar envie uma mensagem para > > >>>> > >>>>>>> dotnetarchitects@googlegroups.com > > >>>> > >>>>>>> Para sair do grupo envie uma mensagem para
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.
<flaviohenriquedecarva...@gmail.com> wrote:
> É um curso de que ? NHibernate ?
> Em 31 de agosto de 2010 13:58, tucaz <tuca...@gmail.com> escreveu:
> > 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:
> > > >>>> 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).
> > > >>>> > > 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.
> > > >>>> > > 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.
> > > >>>> > >>> 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.
> > > >>>> > >>>>> 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.
> > > >>>> > >>>>> 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.
> > > >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com>
> > > >>>> > >>>>>> escreveu:
> > > >>>> > >>>>>> 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.
> 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 ?
>> Em 31 de agosto de 2010 13:58, tucaz <tuca...@gmail.com> escreveu:
>> > 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:
>> > > >>>> 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).
>> > > >>>> > > 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.
>> > > >>>> > > 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.
>> > > >>>> > >>> 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.
>> > > >>>> > >>>>> 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.
>> > > >>>> > >>>>> 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.
>> > > >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz <tuca...@gmail.com> >> > > >>>> > >>>>>> escreveu:
>> > > >>>> > >>>>>> 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.
> 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 ?
> > Em 31 de agosto de 2010 13:58, tucaz <tuca...@gmail.com> escreveu:
> > > 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:
> > > > >>>> 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).
> > > > >>>> > > 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.
> > > > >>>> > > 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.
> > > > >>>> > >>> 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.
> > > > >>>> > >>>>> 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.
> > > > >>>> > >>>>> 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.
> > > > >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz < > tuca...@gmail.com> > > > > >>>> > >>>>>> escreveu:
> > > > >>>> > >>>>>> 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.
>> 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 ?
>> > Em 31 de agosto de 2010 13:58, tucaz <tuca...@gmail.com> escreveu:
>> > > 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:
>> > > > >>>> 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).
>> > > > >>>> > > 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.
>> > > > >>>> > > 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.
>> > > > >>>> > >>> 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.
>> > > > >>>> > >>>>> 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.
>> > > > >>>> > >>>>> 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.
>> > > > >>>> > >>>>>> Em 31 de agosto de 2010 13:13, tucaz >> > > > >>>> > >>>>>> <tuca...@gmail.com> >> > > > >>>> > >>>>>> escreveu:
>> > > > >>>> > >>>>>> 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ê
