< C# Linq to SQL, aumentando o desempenho |
Dica #1: Bagagem Extra
A "Bagagem extra" de um contexto que se utiliza do Linq to SQL é um problema clássico desta metodologia hoje considerada a principal entre os desenvolvedores .NET, prova é, que vem sendo otimizada para cada atualização dos pacotes de Framework desde a versão 3.5.
Quando criamos um contexto para utilizar o Linq ele vem com uma serie de propriedades pré-configuradas para estarem ativas (True), uma delas especificamente tem papel fundamental no desempenho de uma consulta, a ObjectTrackingEnabled(Framework 3.5).
Em programação orientada a objetos as tabelas do banco de dados são representados através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes, quando abrimos um contexto e a propriedade em questão esta em seu estado normal (true), faz com que o mesmo ocupe memória para guardar os valores de cada instância envolvida na consulta para caso houver alteração ele valide as alterações realizadas. Muitas vezes utilizamos um contexto para obtermos retornos com apenas o propósito de ser "ready only", por tanto, não se faz necessário o uso de memória para monitorarmos os valores instanciados.
Para orientarmos o Framework a não guardar o valor das instâncias em nosso contexto setamos ele como false. Veja o exemplo abaixo onde demonstramos em uma simples consulta.
public static List<SourceTipe> VerificaAniversarios() {
using ( var ctxs = new PetShopDataContext(PetShopLib.CUtil.Conection))
ctxs.ObjectTrackingEnabled = false;
Lembrando que existem vários meios de se setar as propriedades de um contexto e o fazê-lo dentro de um método é somente mais uma delas.
Dica #2: Use as projeções para emagrecer suas consultas
Vamos falar sobre duas maneiras de enxugar nossas consultas usando o Linq. Digamos que você tenha uma tabela Aluno que contém 50 campos, mas você esta interessado em três: Nome, Sobrenome, RG. Neste caso temos que ter cuidado ao executar nossa consulta e selecionar somente os campos que precisamos como por exemplo:
var aluno =
( from a in dataContext.Aluno
where a.ID == AlunoID
Aluno.Nome,
Aluno.Sobrenome,
Aluno.RG
Outra maneira muito utilizada é filtrando os dados que queremos selecionar na fonte da busca o banco de dados. Para isso usamos muito views para filtrar apenas os dados que queremos e assim usando a mesma como fonte em nosso método Linq, veja o exemplo abaixo:
public List<T> NomeMétodo()
var SQL = (from ser in ctx.view
O que precisamos cuidar é que desenvolvedores pensam sempre em como economizar esforços e já antecipam futuras funcionalidades carregando suas views com "todos os campos que um dia vou precisar", outra prática comum que pode ser perigosa é usar uma mesma view para mais de uma consulta. Precisamos entender que nem sempre poupar trabalho é o melhor caminho para termos um software com um bom desempenho.
Dica #3: Use LinqPAD para ter certeza do que esta fazendo
Como todos sabemos uma das maiores facilidades do Linq pode ser também uma de suas fraquezas, a facilidade de executar consultas as vezes nos cega referente ao que transportamos de informação realmente útil em nosso contexto, em um dia de trabalho quantas vezes você para para revisar além do resultado de seu método? Quanto tempo você perde iniciando sua aplicação com Breakpoints para avaliar cada processo de um único método?
O LinqPAD pode ser uma ferramente muito útil para você criar qualquer tipo de consulta e avaliar exatamente o que você está transportando de informações pois você tem uma rica formatação de saída:
Então escreva seus métodos certifique-se do seu desempenho e ainda tenha uma ótima experiência de aprendizado.
Não abordamos assuntos profundos de otimização, porém pautamos uma estrada de fácil alcance a todos independente do nível de conhecimento. O desenvolvimento de software é uma área onde alimentamos muitos vícios bons e ruins, mas nunca é demais olhar para o lado do cliente que não vai entender o porque demora tanto para efetuar uma busca hehehe.