Eu não sou um fã de procedimentos armazenados
Os procedimentos armazenados são MAIS fáceis de manter porque:* Você não precisa recompilar seu aplicativo C# sempre que quiser alterar algum SQL
Você acabará recompilando-o de qualquer maneira quando os tipos de dados forem alterados ou desejar retornar uma coluna extra ou qualquer outra coisa. O número de vezes que você pode 'transparentemente' alterar o SQL por baixo do seu aplicativo é muito pequeno no geral
- Você acaba reutilizando o código SQL.
As linguagens de programação, incluindo C#, têm essa coisa incrível, chamada função. Isso significa que você pode invocar o mesmo bloco de código de vários lugares! Incrível! Você pode então colocar o código SQL reutilizável dentro de um desses, ou se quiser obter realmente alta tecnologia, pode usar uma biblioteca que faz isso por você. Eu acredito que eles são chamados de Mapeadores Relacionais de Objetos, e são bastante comuns nos dias de hoje.
A repetição de código é a pior coisa que você pode fazer quando está tentando construir um aplicativo sustentável!
Concordo, e é por isso que os storedprocs são uma coisa ruim. É muito mais fácil refatorar e decompor (dividir em partes menores) código em funções do que SQL em... blocos de SQL?
Você tem 4 servidores da web e vários aplicativos do Windows que usam o mesmo código SQL Agora você percebeu que há um pequeno problema com o código SQl, então você prefere...... alterar o proc em 1 lugar ou enviar o código para todos os servidores da web, reinstale todos os aplicativos da área de trabalho (clique uma vez pode ajudar) em todas as caixas do Windows
Por que seus aplicativos do Windows estão se conectando diretamente a um banco de dados central? Isso parece uma ENORME falha de segurança ali, e um gargalo, pois exclui o cache do lado do servidor. Eles não deveriam estar se conectando por meio de um serviço da Web ou semelhante aos seus servidores da Web?
Então, envie 1 novo sproc ou 4 novos servidores da web?
Neste caso, é mais fácil enviar um novo sproc, mas na minha experiência, 95% das 'alterações enviadas' afetam o código e não o banco de dados. Se você estiver enviando 20 coisas para os servidores da Web naquele mês e 1 para o banco de dados, dificilmente perderá muito se, em vez disso, enviar 21 coisas para os servidores da Web e zero para o banco de dados.
Código mais facilmente revisado.
Você pode explicar como? Eu não entendo isso. Particularmente, visto que os sprocs provavelmente não estão no controle de origem e, portanto, não podem ser acessados por meio de navegadores SCM baseados na Web e assim por diante.
Mais contras:
Os Storedprocs vivem no banco de dados, que aparece para o mundo exterior como uma caixa preta. Coisas simples como querer colocá-los no controle de origem se tornam um pesadelo.
Há também a questão do esforço puro. Pode fazer sentido dividir tudo em um milhão de camadas se você estiver tentando justificar ao seu CEO por que custou apenas 7 milhões de dólares para construir alguns fóruns, mas, caso contrário, criar um storedproc para cada pequena coisa é apenas um trabalho extra para não beneficiar.
