Prática recomendada para consultar dados do MS SQL Server em C #?

Qual é a melhor maneira de consultar dados de um MS SQL Server em C #?

Eu sei que não é uma boa prática ter uma consulta SQL no código.

É a melhor maneira de criar um procedimento armazenado e chamá-lo de C # com parâmetros?

using (var conn = new SqlConnection(connStr))
using (var command = new SqlCommand("StoredProc", conn) { CommandType = CommandType.StoredProcedure }) {
   conn.Open();
   command.ExecuteNonQuery();
   conn.Close();
}

O uso de procedimentos armazenados é uma maneira e tem sido amplamente utilizado por muitos anos.

Uma maneira mais moderna de interagir com os bancos de dados do SQL Server a partir de C # (ou qualquer linguagem .NET) é usar o Entity Framework. A vantagem do Entity Framework é que ele fornece um nível mais alto de abstração.

Para citar a Microsoft ( https://msdn.microsoft.com/en-us/data/jj590134 ):

O ADO.NET Entity Framework permite que os desenvolvedores criem aplicativos de acesso a dados programando em um modelo de aplicativo conceitual em vez de programar diretamente em um esquema de armazenamento relacional. O objetivo é diminuir a quantidade de código e manutenção necessária para aplicativos orientados a dados. Os aplicativos do Entity Framework fornecem os seguintes benefícios:

• Os aplicativos podem funcionar em termos de um modelo conceitual mais centrado em aplicativos, incluindo tipos com herança, membros complexos e relacionamentos.
• Os aplicativos são liberados de dependências codificadas em um mecanismo de dados ou esquema de armazenamento específico.
• Os mapeamentos entre o modelo conceitual e o esquema específico do armazenamento podem mudar sem alterar o código do aplicativo.
• Os desenvolvedores podem trabalhar com um modelo de objeto de aplicativo consistente que pode ser mapeado para vários esquemas de armazenamento, possivelmente implementados em diferentes sistemas de gerenciamento de banco de dados.
• Vários modelos conceituais podem ser mapeados para um único esquema de armazenamento.
• O suporte a consulta integrada à linguagem (LINQ) fornece validação de sintaxe em tempo de compilação para consultas em relação a um modelo conceitual.

O uso de um ORM vs procedimentos armazenados envolve compensações, principalmente em termos de segurança e onde a lógica reside.

A abordagem "clássica" ao desenvolvimento com o SQL Server é fazer com que a lógica do aplicativo resida nos procedimentos e programas armazenados, apenas com direitos de segurança para executar procedimentos armazenados, não para atualizar tabelas diretamente. O conceito aqui é que os procedimentos armazenados são a camada de lógica de negócios para os aplicativos. Embora a teoria seja sólida, ela tende a perder o interesse por várias razões, sendo substituída pela implementação da lógica de negócios em uma linguagem de programação como C # ou VB. Bons aplicativos ainda são implementados com uma abordagem em camadas, incluindo a separação de preocupações etc., mas são mais propensos a seguir um padrão como o MVC.

Uma desvantagem da implementação da lógica no ORM, e não no banco de dados, é a facilidade de depuração e teste das regras de integridade de dados pelos responsáveis ​​pelo banco de dados (DA ou DBA). Pegue o exemplo clássico de transferência de dinheiro da sua conta corrente para a conta poupança, é importante que isso seja feito como uma unidade atômica de trabalho, ou seja, imprensado em uma transação. Se esse tipo de transferência apenas pode ser realizado por meio de um procedimento armazenado, é relativamente fácil para o DA e os auditores controlarem o controle do controle por controle de qualidade.

Se, por outro lado, isso é feito por meio de um ORM como o Entity Framework e na produção, é descoberto que, em raras ocasiões, o dinheiro é retirado da verificação, mas não colocado na depuração da economia, pode ser muito mais complexo, principalmente se vários programas estiverem potencialmente envolvidos. Provavelmente, esse seria um caso extremo, talvez envolvendo problemas peculiares de hardware que precisam ocorrer em uma sequência específica etc. Como testar isso?

Na verdade, a asserção básica é discutível - existem trocas entre o SQL no código ou o código no banco de dados (que é onde você está seguindo os procedimentos armazenados).

O resultado é que não existe um "melhor" único, isso não é algo que você pode generalizar, porque, por qualquer caminho que você vá, você está comprometendo (você obtém benefícios, mas também introduz restrições).

Se houver uma correspondência individual entre o aplicativo e o banco de dados, isso realmente não importa. Se, por outro lado, você tiver um grande banco de dados núcleo compartilhado por um número significativo de aplicativos que impõem consistência no banco de dados entre esses aplicativos, isso se tornará muito mais importante.

O mais importante é se preocupar com a arquitetura e as camadas do seu aplicativo - considerando uma camada de acesso a dados apropriada, usar um ORM como o Entity Framework ou NHibernate ou fazer algo mais direto deve isolar a maioria do seu aplicativo desta decisão, independentemente de você criar consultas ou use procedimentos armazenados.

Terei a liberdade de trabalhar em projetos relativamente pequenos com equipes pequenas (1-3 desenvolvedores) - usar procedimentos armazenados é, para mim, mais problemas do que vale a pena, porque, dada a natureza de nossos aplicativos (e meu conjunto de habilidades?) o código geralmente é muito mais fácil do que atualizar o esquema (mesmo permitindo que eu tenha um código que torne a atualização relativamente simples) e que eu possa impor regras de negócios usando o código comum de acesso a dados. Este é claramente um exemplo clássico de "Sua milhagem pode variar".

Desde que você tenha parametrizado suas entradas, qualquer abordagem é válida. Muitos dos que não têm consultas nos argumentos de código vieram dos velhos tempos ruins, quando muitas das bibliotecas o obrigaram a anexar suas instruções por string e é daí que os ataques de injeção de sql vieram.

As práticas recomendadas são realmente exageradas aqui - há muitas maneiras boas de fazer isso e a que você escolhe deve depender do que é seu aplicativo e do que você precisa fazer. Dito isto, existem apenas duas coisas que você pode fazer realmente errado:

• Como o @Bill aponta, você deve sempre parametrizar suas consultas. A criação de strings é um vetor fácil para injeção de SQL, além de todo tipo de erros difíceis de rastrear. Pessoas muito mais inteligentes descobriram como tupelizar e escapar do sql para que você não precise descobrir sozinho.

• Feche suas conexões. A melhor maneira é envolver tudo em uma declaração de uso, mas try / catch / finalmente também é legal se isso flutua no seu barco. Mas sempre use uma conexão como um carro barato - conduza com força e rapidez e livre-se dela rapidamente.

A outra prática pela qual eu argumentaria veementemente é que você deve se concentrar no código de acesso a dados no menor número possível de lugares. Não permitimos que aplicativos Web front-end mantenham uma referência direta ao System.Data.SqlClient para ajudar a impor essa advertência.