Sorry, this entry is only available in Portuguese.
Software architecture, agile and all that stuff that you can find everywhere
Software architecture, agile and all that stuff that you can find everywhere
Sorry, this entry is only available in Portuguese.
Só falta agora o cursor sair rsrsrsr abração
Quase lá! ehehe
Boas Tucaz,
Você ainda pode optar por utilizar o acesso direto ao índice ao invés do nome da coluna quando utilizar um DataReader. Com isso, você tem acesso direto a informação e de forma tipada, evitando assim a necessidade de conversões e a busca do índice que corresponde a coluna, que é o que ocorre quando passamos o nome da coluna através do indexer.
reader["Id"] para reader.GetInt32(X)
reader["Name"] para reader.GetString(Y)
Onde X e Y são números inteiros que correspondem aos índices da coluna retornadas pelo result-set.
Um outro detalhe é evitar a chamada do método GetType a todo momento quando utilizamos o modelo que constrói via Reflection, pois já sabemos ele, e que neste caso é Product.
Talvez isso ajude em algo.
Att,
Opa Israel!
Com certeza existem maneiras de otimizar ainda mais o código nativo, mas a idéia é mostrar que 1) código nativo é mais rápido que um ORM mas que 2) isso não é motivo pra evitar seu uso
Valeu!
Eu concordo que o uso de Stored Procedure já era até por que os banco de dados modernos já estão inteligentes. Outro ponto importante que observo no uso de um O/R é justamente a tipagem dos dados como objetos e a integração do Visual Studio que facilita a manutenção e aumenta a produtividade.
Tucaz
Teste bastante interesante.
Uma dica para uma nova postagem “na mesma linha” seria a substituição do NHibernate pelo Entity Framework.
Você quer dizer como desenvolver um sistema onde seja possível substituir um ORM por outro?
É possível, mas não vai ser 100% “automático”. Implementar Onion Architecture é um excelente começo: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Não, me referia a realização dos mesmos testes porém com o Entity Framework.
Mas de qualquer maneira eu concordo com você, vão ser poucos os casos ou situações onde o custo x benefício do uso de um OR/M não valerá a pena.
mais uma vez parabéns pelo post.
Valeu!
Vou adicionar este teste aqui na pauta de escrita. Quem sabe até um NH vs EF4?
“NH vs EF4″
vai ser bom ver a porrada comendo
Tucaz, arrebentou! Servirá de referência
.
Uma considerações que faço é: corra com o curso, o mercado precisa aperfeiçoar!
Parabéns pelas medições.
Esse é meu garoto !
=P
Muito bom o post Tucaz! Parabéns!
Muito bom Tucaz. Parabéns.
Usarei como referencia.
Olá Tucaz!
Muito bom o post, interessantíssima a idéia dos testes, show!
Só um comentário: por que não fazer os testes com uma massa de dados um pouco maior? Embora uma grande parte das aplicações seja de CRUD, exibições simples, etc, por ser um comparativo eu creio que fosse muito válido imlplementar com uma massa de alguns milhares de registros.
Abraço!
[...] devo abandonar totalmente o ADO.NET nativo que venho usando. Nem mesmo o bem feito teste do Tucaz, http://blog.tucaz.net/en/2010/08/31/performance-nhibernate-versus-ado-net/ que apreciei a honestidade na apresentação dos resultados, me levaram a titubear de minhas [...]