Se é ruim para usar em linha SQL, como é que usando o LINQ para executar consultas diferem na prática?

votos
13

Qual é o consenso geral sobre o uso de LINQ para executar consultas e em linha manipulação e como isso difere para incorporar instruções SQL em seu código (que é considerado um não não)?

Publicado 27/08/2009 em 03:20
fonte usuário
Em outras línguas...                            


9 respostas

votos
7

Ignorando todos os usos não relacionados com o SQL de LINQ e apenas considerando LINQ to SQL.

Consultas LINQ são objetos que retêm uma consulta definição eo SQL equivalente só é instanciar no momento em que a consulta é realmente iteração. Isso permite que os componentes sejam correctamente separadas e permitir um processamento estilo tubagem onde as consultas são retornados por camadas mais baixas (por ex. Por repositórios) e transformado por componentes de maior sobre a pilha. A consulta pode acomodar novos filtros, junta e outros 'artefatos' de cada componente no tubo de processamento, até atingir a forma final que, eventualmente, é iterado. Esta manipulação é impossível na prática, usando SQL texto reto.

Outra vantagem do LINQ é que a sua sintaxe é mais fácil de compreender para os desenvolvedores não-banco de dados. perícia sintaxe SQL é um surpreendentemente difícil encontrar ativos. Alguns desenvolvedores estão dispostos a gastar tempo aprendendo pontos mais sutis de SQL para alémSELECT * FROM ... WHERE .... A sintaxe linq está mais perto do ambiente quotidiano .Net e aproveita a habilidade existente fixado em que a camada (ex. Expressões lambda) em oposição a forçar o desenvolvedor para aprender o SQL apropriado para o final alvo de volta (T-SQL, PL-SQL etc). Dado que a expressão linq expressa o resultado desejado praticamente em linha reta na álgebra relacional, os fornecedores têm um trabalho muito mais fácil para gerar o SQL apropriado (ou até mesmo gerar diretamente o plano de execução!). Compare isso com a tarefa impossível motoristas de banco de dados 'genéricos' teve que enfrentar preciosamente com texto SQL. Lembre-se ODBC Sintaxe de escape, qualquer um?

Respondeu 27/08/2009 em 03:32
fonte usuário

votos
5

Você está certo: "declaração Embedding SQL em seu código não é ruim." Isto é terrível.

Isso torna a sua aplicação altamente acoplados, frágil e difícil de manter. Pelo menos, se você tem tudo em procs, quando você alterar algo, você pode fazer uma pesquisa sobre dependências.

procs armazenados, eu me sinto realmente precisa ir longe demais para esses procs que estão lidando com lógica de negócios.

A razão é que a lógica de negócios pertence à camada de negócios - e não a camada de dados.

Claro, se o Linq gerado para SQL Acontece algo confuso e lento, você tem que usar uma proc.

Uma das grandes vantagens do LINQ to SQL é que você pode encadear filtros - você está onde cláusula é apenas adicionados dinamicamente através de sua lógica, conforme necessário. Você não precisa criar novos procs só porque você quer chamar para um conjunto de dados com base em vários parâmetros.

Respondeu 27/08/2009 em 04:01
fonte usuário

votos
1

Duas vantagens de "LINQ to SQL" contra (o comum pior caso de) "SQL inline" .

Os parâmetros são tratados como parâmetros, e não apenas como texto concatenadas - este supera problemas de injeção de SQL.

A camada de modelo separado permite tempo de compilação verificação de que o SQL gerado irá coincidir com o esquema. (No pior caso de SQL embutido, você não teria nenhuma maneira de saber em tempo de compilação se você estivesse fazendo referência a uma coluna que tinha sido excluído, por exemplo)

Respondeu 27/08/2009 em 03:27
fonte usuário

votos
1

Incorporação instrução SQL em seu código não é ruim. Tudo depende de qual camada do seu aplicativo que você está escrevendo.

Tudo o que está relacionado com a leitura e escrita para o armazenamento de dados, deve ser na camada de acesso a dados.

Respondeu 27/08/2009 em 03:25
fonte usuário

votos
0

Ter trabalhado extensivamente com SQL incorporado, o perigo real é que ele é uma tecnologia de geração de código. Você escrever código C (ou qualquer outro idioma) e, em seguida, você alternar para SQL, depois de volta para C novamente. Mais tarde, antes da compilação um prepocessor reescreve o código para ser tudo o C. Os resultados podem gerar mensagens de erro muito confuso. Você é forçado a aprender a API para interagir com o banco de dados que SQL embutido era para livrá-lo de. Finalmente, você corre o risco de incorporar regras de negócios em suas consultas confundindo a camada de negócios e camada de dados. Linq evita algumas destas questões. Primeiro, Linq é parte da linguagem. As construções funcionam mais ou menos como um programador de espera. Há alguma sintaxe tipo SQL envolvidos, mas principalmente a sintaxe é focada na linguagem hospedeira (ou seja, C #). As verificações de compilação são feitas no código real que você escreveu. Mesmos não há necessidade de traduzir os erros na sintaxe antes de pré-processamento. Os resultados da consulta são objetos e coleções, tal como seria de esperar. Há ainda o perigo de misturar lógica de negócios na camada de dados no entanto. Além disso, Linq tem suas próprias questões com mensagens de erro onde o campo em questão muitas vezes não está incluído. Ainda assim, é um bom compromisso entre o mundo dos objetos e do mundo relacional.

Respondeu 17/08/2010 em 14:26
fonte usuário

votos
0

Em algum linha de código, alguém, em algum momento, vai decidir se é apropriado para digitar o SQL. Mas, em vez de fazer isso, você vai usar LINQ.

Portanto, não é uma questão se LINQ deve ser embutido quando o SQL não deveria. A questão é onde você quer que sua representação acesso de armazenamento de dados para ser. Se você estiver escrevendo LINQ em algum linha de código, e você não se sentir confortável deste escopo ter acesso aos dados armazenados, então é o lugar errado.

LINQ é apenas uma abstração para manipulação de dados. É um atalho para conjuntos de filtragem. Assim como os bancos de dados SQL entender, o ambiente .NET tem uma linguagem para falar com os dados.

Qual é a diferença entre o LINQ e fazer if dentro de um loop, em dados que vieram de um arquivo ou uma tomada de rede? Nenhum, é apenas a sintaxe. Se você SELECT * FROM table, filtrando todas as linhas de uma função, que é a diferença de fazer where c.SomeProperty < xcom o LINQ? Apenas a sintaxe.

Claro, LINQ sabe e fazer mais do que simplesmente retornar linhas de uma base de dados. Ele permite que você instanciar objetos de uma coleção, mas o mesmo acontece = new ClassName(column1, colum2)a partir dos resultados instrução SQL.

Em suma, se em algum lugar escrevendo em linha SQL em seu código é um não-não, por isso deve estar escrevendo LINQ.

Mas isso varia de projeto para projeto. Databases principalmente entender SQL, assim, pelo menos em algum lugar no seu código, biblioteca ou ambiente não são inlined SQLs.

Respondeu 27/08/2009 em 03:49
fonte usuário

votos
0

Da minha pouca compreensão, se você usa LINQ to SQL ou qualquer outro ORM ou seu próprio código que envolve chamadas SQL, é basicamente o que lhe dá uma abstração em que você não precisa se preocupar com SQL.

Além disso, se eu estiver correto - LINQ to SQL suporta apenas SQL Server.
Eu acho, que permite construir seus critérios de SQL como forma usando a sintaxe LINQ.

Pessoalmente, eu não sei por que alguém iria usar LINQ to SQL.
Pode um especialista me ajudar a entender a necessidade dele?

Respondeu 27/08/2009 em 03:34
fonte usuário

votos
0

Olhando para as outras respostas, talvez eu não entendi a pergunta ... mas eu estou falando sobre LINQ normais em coleções em C #, não LINQ to SQL:

Quando você incorpora SQL declarações no seu código (em oposição a fazê-los variáveis ou de outra forma parametrizar o seu SQL), você está tornando-se muito mais difícil para si mesmo se você quiser apoiar um banco de dados diferente no futuro. Tão antiga e padronizada como SQL é, ainda existem muitas incompatibilidades entre fornecedores.

Com LINQ, a portabilidade não é mais um problema - seu código é escrito em C # e LINQ é C #.

Respondeu 27/08/2009 em 03:31
fonte usuário

votos
0

Por um lado instruções LINQ são parametrizados - consultas em linha não são necessariamente assim. Por outro lado, LINQ basicamente cria uma camada ORM - permitindo objectos de dados a ser tratados essencialmente como objectos dentro do código - proporcionar o tempo de compilação verificação. Uma consulta em linha, por outro lado é uma bolha de texto que não vai quebrar em tempo de compilação ...

Respondeu 27/08/2009 em 03:28
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more