Hoje, vamos falar uns truques simples com strings no C#. Eu sei que pode ser demasiado óbvio e repetido pela internet fora, mas ainda assim quero dar a minha opinão sobre o assunto. Vamos a isto!
Imaginemos que temos uma List de qualquer type e vamos precisar dos seus valores separados por uma vírgula para serem enviados para uma stored procedure. O resultado desejado será, dada uma List de {1,2,3,4}, uma string neste formato: "1,2,3,4". Como vamos resolver este problema? Já vi e fiz múltiplas soluções para o problema, por isso vamos ordenar as possíveis soluções (na minha cabeça) da mais complexa para a mais simples. Primeiro, podemos fazer isto:
Vejam o quão complexo isto pode ser e o quão rapidamente se pode tornar insustentável. Quando repetido múltiplas vezes num projecto (imaginem ter isto repetido na vossa Camada de Acesso a Dados sempre que uma stored procedure precisa deste input), isto pode tornar-se doloroso. Claro que poderiamos extrair este comportamento para um extension method, mas como iremos ver isto não é necessário.
A nossa segunda abordagem, muito mais simples, utiliza todo o poder que LINQ nos traz. LINQ é uma daquelas tecnologias que eu adoro no .NET. Pode simplificar-vos muito a vida quando aplicado correctamente. Mas vamos ver como poderiamos fazê-lo neste caso:
Ainda assim, esta não é a nossa melhor solução. Vamos admitir, aquele uso do Aggregate e do Remove pode ser complicado de compreender à primeira vista. Na verdade, isto até fica pouco legível e temos que estar familiarizados com a forma como o Aggregate trabalha. Também veremos o quão horrivelmente lento é utilizar este método.
Vamos ver o próximo snippet:
Esta solução é simples, de fácil manutenção, fácil de compreender à primeira vista e, esperemos, com boa performance. Será mesmo? Vamos correr alguns testes e verificar! Para isso, preenchi a variável DocumentIDs com 10 000 000 ints, extraí cada uma das abordagens para um método e chamei-o 5 vezes envolvido num Stopwatch. Depois dividi o resultado em milisegundos por 5 para obter a média. Sim, eu sei que não é um benchmark de qualidade, mas serve para este exemplo.
Na altura dos testes eu tinha um Toshiba Satellite L40, Intel Pentium T2330 @ 1.6GHz e 2GB de RAM. Vamos ver os resultados:
Foreach com StringBuilder (Snippet 1): 4773 ms em média (Corri 5 vezes)
Não está mau de todo! Normalmente também nunca estaríamos a lidar com uma quantidade de dados desta natureza, mas é sempre bom ver como as várias opções se comportam sob pressão.
Aggregate com Remove (Snippet 2): acima de 1m:30s (Corri apenas uma vez. Não o deixei sequer acabar.)
Podemos ver que esta não é uma boa abordagem. Para começar, utilizar LINQ nesta situação é como matar moscas com canhões. Notem que estou a concatenar a string com o operador (+). Esta operação é extremamente lenta porque uma string é imutável e de cada vez uma nova string tem que ser instanciada. Portanto, esta não será a solução ideal.
String.Join (Snippet 3): 4670 ms em média (Corri 5 vezes)
Como podemos ver, o terceiro método é o mais rápido também. O primeiro também não lhe fica muito atrás, mas vamos manter as coisas simples. String.Join foi desenhado especificamente para estes casos, portanto vamos utilizar o que a framework nos oferece!
Se há uma lição que eu retiro deste tipo de situações é: não reinventes a roda quadrada. Todos nós o fazemos uma vez ou outra, é a nossa natureza como programadores, mas isso apenas importa se aprendermos algo com isso. Eu acredito que cada uma das abordagens tenha as suas vantagens e desvantagens. Por exemplo, consigo imaginar-me a utilizar a primeira abordagem para encapsular outro comportamente também quando o método fosse chamado, ou para formatar o output de outras formas mais personalizadas.
Sintam-se à vontade em partilhar outras formas de resolver o mesmo problema,
Obrigado pela leitura!
Links and references:
String.Join no MSDN
http://msdn.microsoft.com/en-us/library/57a79xd0.aspx
StringBuilder no MSDN
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx
Aggregate no MSDN
http://msdn.microsoft.com/en-us/library/bb548651.aspx
---------------------------------------------------------------------------------
Nota de rodapé:
Ao longo do tempo vou começar a actualizar o meu blogue para também incluir os posts em Português. Esta é a minha lingua materna e considero importante também chegar a quem não tem conhecimentos de inglês. No entanto não vou traduzir todos os termos para Português porque continuo a defender que será melhor procurá-los em Inglês, que é a linguagem geralmente aceite em fóruns internacionais. Qualquer termo que precisem explicado sintam-se à vontade para perguntar.
Imaginemos que temos uma List de qualquer type e vamos precisar dos seus valores separados por uma vírgula para serem enviados para uma stored procedure. O resultado desejado será, dada uma List de {1,2,3,4}, uma string neste formato: "1,2,3,4". Como vamos resolver este problema? Já vi e fiz múltiplas soluções para o problema, por isso vamos ordenar as possíveis soluções (na minha cabeça) da mais complexa para a mais simples. Primeiro, podemos fazer isto:
Vejam o quão complexo isto pode ser e o quão rapidamente se pode tornar insustentável. Quando repetido múltiplas vezes num projecto (imaginem ter isto repetido na vossa Camada de Acesso a Dados sempre que uma stored procedure precisa deste input), isto pode tornar-se doloroso. Claro que poderiamos extrair este comportamento para um extension method, mas como iremos ver isto não é necessário.
A nossa segunda abordagem, muito mais simples, utiliza todo o poder que LINQ nos traz. LINQ é uma daquelas tecnologias que eu adoro no .NET. Pode simplificar-vos muito a vida quando aplicado correctamente. Mas vamos ver como poderiamos fazê-lo neste caso:
Ainda assim, esta não é a nossa melhor solução. Vamos admitir, aquele uso do Aggregate e do Remove pode ser complicado de compreender à primeira vista. Na verdade, isto até fica pouco legível e temos que estar familiarizados com a forma como o Aggregate trabalha. Também veremos o quão horrivelmente lento é utilizar este método.
Vamos ver o próximo snippet:
Esta solução é simples, de fácil manutenção, fácil de compreender à primeira vista e, esperemos, com boa performance. Será mesmo? Vamos correr alguns testes e verificar! Para isso, preenchi a variável DocumentIDs com 10 000 000 ints, extraí cada uma das abordagens para um método e chamei-o 5 vezes envolvido num Stopwatch. Depois dividi o resultado em milisegundos por 5 para obter a média. Sim, eu sei que não é um benchmark de qualidade, mas serve para este exemplo.
Na altura dos testes eu tinha um Toshiba Satellite L40, Intel Pentium T2330 @ 1.6GHz e 2GB de RAM. Vamos ver os resultados:
Foreach com StringBuilder (Snippet 1): 4773 ms em média (Corri 5 vezes)
Não está mau de todo! Normalmente também nunca estaríamos a lidar com uma quantidade de dados desta natureza, mas é sempre bom ver como as várias opções se comportam sob pressão.
Aggregate com Remove (Snippet 2): acima de 1m:30s (Corri apenas uma vez. Não o deixei sequer acabar.)
Podemos ver que esta não é uma boa abordagem. Para começar, utilizar LINQ nesta situação é como matar moscas com canhões. Notem que estou a concatenar a string com o operador (+). Esta operação é extremamente lenta porque uma string é imutável e de cada vez uma nova string tem que ser instanciada. Portanto, esta não será a solução ideal.
String.Join (Snippet 3): 4670 ms em média (Corri 5 vezes)
Como podemos ver, o terceiro método é o mais rápido também. O primeiro também não lhe fica muito atrás, mas vamos manter as coisas simples. String.Join foi desenhado especificamente para estes casos, portanto vamos utilizar o que a framework nos oferece!
Se há uma lição que eu retiro deste tipo de situações é: não reinventes a roda quadrada. Todos nós o fazemos uma vez ou outra, é a nossa natureza como programadores, mas isso apenas importa se aprendermos algo com isso. Eu acredito que cada uma das abordagens tenha as suas vantagens e desvantagens. Por exemplo, consigo imaginar-me a utilizar a primeira abordagem para encapsular outro comportamente também quando o método fosse chamado, ou para formatar o output de outras formas mais personalizadas.
Sintam-se à vontade em partilhar outras formas de resolver o mesmo problema,
Obrigado pela leitura!
Links and references:
String.Join no MSDN
http://msdn.microsoft.com/en-us/library/57a79xd0.aspx
StringBuilder no MSDN
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx
Aggregate no MSDN
http://msdn.microsoft.com/en-us/library/bb548651.aspx
---------------------------------------------------------------------------------
Nota de rodapé:
Ao longo do tempo vou começar a actualizar o meu blogue para também incluir os posts em Português. Esta é a minha lingua materna e considero importante também chegar a quem não tem conhecimentos de inglês. No entanto não vou traduzir todos os termos para Português porque continuo a defender que será melhor procurá-los em Inglês, que é a linguagem geralmente aceite em fóruns internacionais. Qualquer termo que precisem explicado sintam-se à vontade para perguntar.
Comments
Post a Comment