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

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?

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.

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.

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.

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.

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).

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.