Os procedimentos armazenados violam a separação em três camadas?

41

Alguns colegas meus disseram-me que ter lógica de negócios em procedimentos armazenados no banco de dados viola a arquitetura de separação em três camadas, pois o banco de dados pertence à camada de dados, enquanto os procedimentos armazenados são a lógica de negócios.

Eu acho que o mundo seria um lugar muito sombrio sem procedimentos armazenados.

Eles realmente violam a separação em três níveis?

Tulains Córdova
fonte
9
Basta perguntar-lhes se eles não ouviu falar da arquitetura 3 1/2 camadas ...
dreza
7
Lembre-se de que camadas e camadas não são a mesma coisa.
NoChance
2
@ emmad-kareem Esta pergunta me ajudou ( stackoverflow.com/questions/120438/… ). O problema é que a literatura técnica da língua espanhola (minha língua materna) usa uma única palavra para ela ("capa"), enquanto o inglês tem duas palavras muito distintas.
Tulains Córdova
1
@ user1598390, você está certo, pode ficar confuso, especialmente porque o mundo do software não possui rigor suficiente no que diz respeito às definições em um idioma e muito menos em idiomas.
NoChance
1
A arquitetura de três camadas é um conceito lógico, não físico. Você pode implementar regras de negócios usando procedimentos armazenados e, enquanto estão fisicamente no banco de dados, esses procedimentos armazenados ainda fazem parte da camada de lógica de negócios.
Craig

Respostas:

33

Seus colegas estão confundindo arquitetura com implementação.

A idéia por trás de um aplicativo de várias camadas é simplesmente que ele é dividido em partes que encapsulam certos tipos de processamento (armazenamento, lógica de negócios, apresentação) e se comunicam entre si usando interfaces bem definidas. Assim como é possível fazer com êxito coisas que se assemelham à programação orientada a objetos em linguagens não orientadas a objetos, é possível fazer o mesmo com várias camadas em um ambiente, como um servidor de banco de dados. O que qualquer um dos que têm sucesso em comum é a necessidade de cuidado, disciplina e compreensão dos compromissos envolvidos.

Vejamos um aplicativo de três camadas em que duas das camadas foram implementadas em um banco de dados:

  • Dados Nível: Consiste em tabelas de banco de dados acessados usando as quatro operações de tabela padrão ( INSERT, UPDATE, DELETEe SELECT).
  • Camada lógica: consiste em procedimentos armazenados que implementam apenas a lógica comercial e acessam a camada de dados usando apenas os métodos descritos acima.
  • Camada de apresentação: Consiste em um servidor Web executando código que acessa a camada lógica, fazendo apenas chamadas de procedimento armazenado.

Este é um modelo perfeitamente aceitável, mas vem com algumas vantagens. A lógica de negócios é implementada de uma maneira que fornece acesso rápido e fácil à camada de dados e pode permitir que coisas que deveriam ser feitas "da maneira mais difícil" por uma camada lógica fora do banco de dados. O que você desiste é a capacidade de mover facilmente qualquer camada para outra tecnologia e implementação despreocupada (ou seja, você deve ter cuidado extra para que as camadas não usem recursos disponíveis no banco de dados, mas fora de suas interfaces definidas) .

Se esse tipo de coisa e as compensações trazidas são aceitáveis ​​em uma determinada situação, é algo que você e seus colegas precisam determinar usando seu julgamento.

Blrfl
fonte
2
Para que eu possa concluir que os procedimentos armazenados fazem parte da camada lógica, em termos de arquitetura, independentemente do fato de estarem armazenados no banco de dados?
Tulains Córdova 22/10/12
3
@ user1598390: sim. Embora fosse uma camada dizer 3 camadas, e não 3 camadas.
jmoreno
4
@ user1598390: Você pode dizer isso desde que possa provar. Na primeira vez que a camada de apresentação SELECTé diretamente das tabelas (a camada de dados), o modelo foi quebrado.
Blrfl
@blrfl Isso é algo que eu cuidei;) #
Tulains Córdova
2
@ user1598390: tudo bem, lembre-se de que o objetivo é a separação lógica de preocupações, não colocando coisas em hardware diferente.
jmoreno
19

Os procedimentos armazenados são poderosos o suficiente para permitir que você codifique uma violação da separação em três camadas, trazendo a lógica de negócios para a camada RDBMS. No entanto, esta é uma decisão sua, não uma falha inerente aos procedimentos armazenados. Você pode limitar seus SPs para atender às necessidades da camada de dados, mantendo a lógica do aplicativo na camada de aplicativos da arquitetura.

Há uma exceção rara, mas importante, à regra de separação, quando você precisa de procedimentos armazenados (especificamente, um grupo de gatilhos) para conter a lógica de negócios. Isso acontece quando seu aplicativo precisa produzir muitas agregações de dados dinâmicas que atingem milhões de linhas. Em casos como esse, os acionadores podem ser configurados para manter dados pré-agregados para uso da camada de negócios. Isso deve ser feito apenas em situações em que, sem pré-agregação, seu aplicativo seria inaceitavelmente lento.

dasblinkenlight
fonte
7
+1 por mencionar que, ocasionalmente, você deseja que alguma lógica resida no banco de dados por motivos de desempenho, porque um RDBMS geralmente define ordens de magnitude de operações mais rapidamente que o código do aplicativo. Embora obviamente isso ocorra apenas quando o desempenho é crítico e não pode ser atendido no código do aplicativo, a grande maioria dos aplicativos modernos suportados por banco de dados são aplicativos CRUD e têm zero uso para tais benefícios.
Jimmy Hoffa
1
um homem. As pessoas parecem pensar que sprocs = "código" comercial. Eles devem ser considerados como uma 'API' do banco de dados e, em seguida, fazem muito mais sentido. Obviamente, eles também podem corrigir os casos extremos onde você também precisa de desempenho de sua lógica!
Gbjbaanb
5

Os conselhos de Atwood de 2004 soam verdadeiros ainda hoje, mas agora também temos o benefício da ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Os procedimentos armazenados devem ser considerados na linguagem de montagem do banco de dados: para uso apenas nas situações mais críticas de desempenho. Existem várias maneiras de projetar uma camada de acesso a dados sólida e de alto desempenho sem recorrer a procedimentos armazenados; você obterá muitos benefícios se continuar com o SQL parametrizado e um único ambiente de desenvolvimento coerente.

Patrick Szalapski
fonte
Nos meus 20 anos de experiência em uma grande empresa, os procedimentos armazenados não são usados ​​para retornar linhas (as visualizações são usadas para isso), nem para todas as inserções ou atualizações simples (sql inline é usado para isso). Eles são usados ​​principalmente para operações longas que não exigem interação do usuário, exigindo iteração de grandes conjuntos de dados para resumir e fazer inserções ou atualizações com base em alguma lógica de negócios, em uma base de linha, como fechamentos de final de traça ou processamento diário de transações em lote . O autor do artigo parece estar usando procedimentos armazenados para retornar linhas e é por isso que ele os aquece.
Tulains Córdova
3

Resumo: Depende realmente do uso de procedimentos armazenados e dos requisitos de negócios.

Existem vários projetos que usam uma arquitetura de três camadas e, dependendo da natureza dos requisitos de negócios, pode ser necessário mudar algumas operações para uma camada de dados.

Falando sobre terminologia, em geral, essas camadas são descritas como:

  • A camada de apresentação ou camada de serviços do usuário - fornece ao usuário acesso ao aplicativo.
  • A camada intermediária , ou camada de serviços de negócios - consiste em regras de negócios e dados.
  • A camada de dados ou camada de serviços de dados - interage com dados persistentes geralmente armazenados em um banco de dados ou em armazenamento permanente.

Normalmente, para a arquitetura fornecida, a camada intermediária ou a camada de serviços de negócios consiste em regras de negócios e dados. No entanto, às vezes faz grande diferença mudar operações pesadas da base de conjuntos e / ou regras de dados a serem executadas no nível de dados - por meio de um conjunto de procedimentos armazenados.

Os benefícios dos projetos de três camadas são:

Durante o ciclo de vida de um aplicativo, a abordagem em três camadas oferece benefícios como reutilização, flexibilidade, capacidade de gerenciamento, manutenção e escalabilidade. Você pode compartilhar e reutilizar os componentes e serviços criados e distribuí-los por uma rede de computadores, conforme necessário. Você pode dividir projetos grandes e complexos em projetos mais simples e atribuí-los a diferentes programadores ou equipes de programação. Você também pode implantar componentes e serviços em um servidor para ajudar a acompanhar as alterações, e pode reimplantá-los à medida que aumenta o crescimento da base de usuários, dados e volume de transações do aplicativo.

Portanto, é realmente uma abordagem baseada em casos que possui vantagens e desvantagens. No entanto, as diretrizes de design da Microsoft do Modelo de arquitetura de três camadas recomendam manter a lógica de negócios na camada intermediária.

EL Yusubov
fonte
2

Camada significa máquina diferente, camada significa separação lógica diferente. Com procedimentos armazenados, você tem a camada de dados e (pelo menos parte) a camada de lógica de negócios na mesma camada. A colocação da lógica de negócios nos procedimentos armazenados viola a arquitetura de três cansados, mas é questionável se viola uma arquitetura de três camadas; Uma coisa certa é que com certeza não é um bom exemplo de separação de preocupações.

Uma camada é um mecanismo de estruturação lógica para os elementos que compõem sua solução de software; uma camada é um mecanismo de estruturação física para a infraestrutura do sistema. ( Referência )

Na minha opinião, existem dois grandes problemas com a construção de lógica de negócios no banco de dados:

  1. Código e bibliotecas: você encontrará menos programadores capazes de programar em SQL, PL / SQL, TSQL etc. do que em C #, Java etc. As linguagens de programação também têm a vantagem de excelentes IDEs, ótimas bibliotecas e estruturas.

  2. Escalabilidade horizontal: a única maneira de escalar seu sistema é alterando o servidor físico no qual o banco de dados é mais poderoso, o que é bastante caro (um servidor com 64 GB de RAM); os bancos de dados relacionais são dimensionados horizontalmente muito ruins e até com maiores custos. Embora, com a lógica de negócios no servidor construído em OO, você possa escalar horizontalmente muito bem, colocando o servidor em muitos nós (em Java, muitos servidores de aplicativos suportam isso).

m3th0dman
fonte
-1

Tivemos esse debate em nosso escritório algumas vezes atrás, eu estava favorecendo o desenvolvimento de banco de dados, tenho a seguinte visão sobre ele

  1. Se você estiver usando o Oracle Database, deve utilizar o PL / SQL o máximo possível, porque com certeza as empresas que investem permanecerão no oracle por pelo menos 10 anos a partir de agora. Enquanto nos aplicativos de ontem você estava usando o Oracle Forms, hoje os formulários da Web .net, o MVC e amanhã você usará o angularjs e só precisará de apis restfull. Se sua lógica máxima estiver no banco de dados, você poderá migrar facilmente para as novas tecnologias de front-end.
  2. O desenvolvimento do banco de dados é muito rápido e muito eficiente em termos de desempenho. Só para lhe dar uma perspectiva. Em nosso projeto, havia 7 desenvolvedores de aplicativos e um desenvolvedor de banco de dados, e 80% da lógica estava no banco de dados.
  3. Se você estiver usando o oracle, poderá usar utilitários para converter diretamente os procedimentos do banco de dados em Res full Api.

O argumento mais forte dos desenvolvedores de aplicativos é que a lógica de negócios deve ser independente do banco de dados, para que você possa alterá-lo facilmente. Eu acho que se uma empresa está usando a Oracle por que eles mudam para outra tecnologia, as chances de tornar a lógica do aplicativo obsoleta são mais esperadas. A questão é principalmente o talento novo do recurso de banco de dados que está faltando, principalmente os caras iniciam sites simples onde eles estão usando mysql ou sqlserver. Esses caras se tornam líderes seniores e têm apego emocional à camada de aplicação :) eles nem querem entender ou debater.

Farhan Ali
fonte
"Se você estiver usando o Oracle Database, você deve utilizar o PL / SQL o máximo possível". Os procedimentos armazenados adicionam carga ao que normalmente é o sistema de gargalo e difícil de escalar em uma arquitetura. Eles também são difíceis de gerenciar, do ponto de vista do controle de versão e dos testes de unidade "Porque com certeza as empresas que investem permanecerão no oracle por pelo menos dez anos a partir de agora". Isso é apenas um absurdo. O que te faz pensar isso? Se você encher seu sistema com lixo estúpido de procedimento PL / SQL, poderá impedir que uma empresa mude para algo contemporâneo. Isso pode ser verdade.
JimmyJames