Um problema comum ao usar javascript combinado com code behind para exibir alertas e o uso de aspas simples e duplas dentro da mensagem.E um problema simples mas a busca pela solucao da trabalho.Encontrei uma solucao simples (aqui) caso o resultado deva ser apresentando como uma URL (por exemplo substituindo espacos por %20). Basta incluir uma referencia a biblioteca Microsoft.JScript.dll e utilizar a funcao Microsoft.JScript.GlobalObject.escape() que devolve o texto codificado.Para o caso de substituir as aspas por \' so encontrei (aqui) codigo que deve ser implementado manualmente.public static string EncodeJsString(string s){ StringBuilder sb = new StringBuilder(); sb.Append("\""); foreach (char c in s) { switch (c) { case '\"': sb.Append("\\\""); break; case '\\': sb.Append("\\\\"); break; case '\b': sb.Append("\\b"); break; case '\f': sb.Append("\\f"); break; case '\n': sb.Append("\\n"); break; case '\r': sb.Append("\\r"); break; case '\t': sb.Append("\\t"); break; default: int i = (int)c; if (i < 32 || i > 127) { sb.AppendFormat("\\u{0:X04}", i); } else { sb.Append(c); } break; } } sb.Append("\""); return sb.ToString();} O LINQ nao e nenhuma novidade e ja esta disponivel a alguns anos. Junto com a biblioteca foram introduzidas novas construcoes na linguagem que permitiram o uso da nova sintaxe.Encontrei um artigo muito interessante contando um pouco de sua historia e mostrando as alteracoes introduzidas na linguagem. Alguns exemplos sao: classes anonimas, tipo var, extension methods, etc.Sobre as classes anonimas, vi uma solucao muito elegante para criar uma colecao generica (System.Collections.Generics.List) de um tipo anonimo. Achei genial, muito criativo.Minha opiniao e, se bem usados, os novos recursos introduzidos ajudam a solucionar alguns dos problemas ao usar classes puras (POCO) para alimentar componentes visuais, mas, acredito ser necessario moderar no uso, ja que e uma nova sintaxe ainda nao tao conhecida pelos programadores brasileiros. Outro dia me questionaram a respeito do problema de desempenho associado ao fato de se abrir e fechar a conexao ao banco de dados a cada chamada de metodo da camada de acesso a dados.Minha opiniao era de que a diferenca nao era relevante.De fato, abrir um conexao com um banco de dados e bastante trabalhoso (para o sistema) e causaria lentidao se fosse feita a cada chamada de metodo, no entanto, o Framework cria um pool de conexoes que funciona de forma transparente para o programador, assim, nao se abrem diversas conexoes, apenas uma quantidade pre-determinada delas e as reutiliza.Resolvi fazer alguns testes comparativos para comprovar isso.Primeiramente medi o tempo gasto para abrir e fechar conexoes comparando o cenario com pool e sem pool.[TestMethod()]public void TesteAbrirFecharConexao(){ SqlConnectionStringBuilder sb = new SqlConnectionStringBuilder(); sb.DataSource = "meuservidor"; sb.InitialCatalog = "meubancodedados"; sb.UserID = "meuususario"; sb.Password = "senha"; sb.PersistSecurityInfo = true; sb.IntegratedSecurity = false; sb.Pooling = true; using (SqlConnection conn = new SqlConnection(sb.ConnectionString)) { Stopwatch watch = new Stopwatch(); watch.Start(); for (int i = 0; i < 1000; i++) { conn.Open(); conn.Close(); } watch.Stop(); Debug.WriteLine("Tempo total: " + watch.ElapsedMilliseconds); }}Obtive os tempos de 137 ms utilizando pooling e 15 segundos sem pooling. Uma diferenca da ordem de 100 vezes.Em seguida comparei o tempo gasto abrindo e fechando a conexao apenas uma vez com o tempo gasto fazendo isso a cada iteracao. A