Os procedimentos armazenados violam a separação em três níveis?

40

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

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

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

    
por Tulains Córdova 21.10.2012 / 22:35
fonte

6 respostas

31

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

A ideia por trás de um aplicativo de várias camadas é simplesmente dividida 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 sucesso coisas que se assemelham a programação orientada a objetos em linguagens não orientadas a objeto, é possível fazer o mesmo com várias camadas dentro de um ambiente, como um servidor de banco de dados. O que fazer com que ambos tenham sucesso em comum é a necessidade de cuidado, disciplina e compreensão dos compromissos envolvidos.

Vamos dar uma olhada em um aplicativo de três camadas em que duas das camadas foram implementadas em um banco de dados:

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

Este é um modelo perfeitamente aceitável, mas vem com algumas compensações. A lógica de negócios é implementada de uma maneira que fornece acesso rápido e fácil à camada de dados e permite fazer coisas que devem 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 outro pouco de tecnologia e implementação despreocupada (isto é, é preciso ter muito cuidado para que as camadas não usem recursos que estão disponíveis no banco de dados, mas fora de suas interfaces definidas) .

Se esse tipo de coisa ou não e as trocas que isso traz são aceitáveis em uma determinada situação, é algo que você e seus colegas têm que determinar usando seu julgamento.

    
por 22.10.2012 / 04:36
fonte
19

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

Há uma exceção rara, mas importante, à regra da separação, quando você precisa de procedimentos armazenados (especificamente, um grupo de acionadores) para conter a lógica de negócios. Isso acontece quando seu aplicativo precisa produzir muitas agregações de dados imediatas que afetam 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 a pré-agregação, seu aplicativo seria inaceitavelmente lento.

    
por 21.10.2012 / 23:07
fonte
3

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

Há 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 palavras gerais, estas 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 normalmente armazenados em um banco de dados ou em armazenamento permanente.

Geralmente, para a arquitetura fornecida, camada intermediária ou camada de serviços de negócios, consiste em regras de negócios e de dados. No entanto, às vezes, faz grande diferença trocar operações de base de conjuntos pesados e / ou regras de dados a serem feitas em camada de dados - por meio de um conjunto de procedimentos armazenados.

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

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Assim, é realmente uma abordagem de caso-base que tem trade-offs em si. No entanto, as diretrizes de design da Microsoft do Modelo de arquitetura de três camadas recomenda manter sua lógica de negócios na camada intermediária.

    
por 22.10.2012 / 04:22
fonte
3

O conselho de Atwood de 2004 ainda é verdade, mas agora temos o benefício do ORM também.

link

Stored Procedures should be considered database assembly language: for use in only the most performance critical situations. There are plenty of ways to design a solid, high performing data access layer without resorting to Stored Procedures; you'll realize a lot of benefits if you stick with parameterized SQL and a single coherent development environment.

    
por 04.12.2014 / 16:21
fonte
2

O nível realmente significa máquina diferente, camada significa separação lógica diferente. Com os procedimentos armazenados, você tem a camada de dados e (pelo menos parte dela) a camada de lógica de negócios na mesma camada. Colocar a lógica de negócios nos procedimentos armazenados viola a arquitetura 3-tired, mas é questionável se ela viola uma arquitetura de 3 camadas; Uma coisa certa é que com certeza não é um bom exemplo de separação de interesses.

A layer is a logical structuring mechanism for the elements that make up your software solution; a tier is a physical structuring mechanism for the system infrastructure. (Reference)

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

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

  2. Escalabilidade horizontal: a única maneira de dimensionar 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); bancos de dados relacionais escala horizontalmente muito ruim, e até mesmo em maiores despesas. Embora, com a lógica de negócios no servidor construído em OO, você possa dimensionar horizontalmente muito bem colocando o servidor em muitos nós (em Java, muitos servidores de aplicativos suportam isso).

por 05.07.2013 / 08:48
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 opinião sobre ele

  1. Se você está usando o banco de dados Oracle, deve utilizar o máximo possível a PL / SQL, porque, com certeza, as empresas que investem ficarão fiéis à Oracle pelo menos daqui a 10 anos. Enquanto nos aplicativos de ontem você estava usando o Oracle Forms, hoje .net Web forms, então MVC, então amanhã você usará o angularjs e precisará apenas de restfull apis. Se a lógica máxima estiver no banco de dados, você poderá migrar facilmente para as novas tecnologias front-end.
  2. O desenvolvimento de banco de dados é muito rápido e muito eficiente em desempenho. Só para te 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 seus procedimentos de banco de dados em Res Api completa.

O argumento mais strong dos desenvolvedores de aplicativos é que a lógica de negócios deve ser independente do banco de dados para que você possa alterar facilmente o banco de dados. Eu acho que se uma empresa está usando o oracle por que eles irão mudar para outra tecnologia, em vez disso, as chances de obter a lógica do aplicativo obsoleta são mais esperadas. A questão é na maioria dos novos talentos do recurso de banco de dados está faltando, principalmente os caras começam sites simples onde eles estão usando o mysql ou sqlserver. Esses caras, em seguida, se tornam líderes seniores e têm apego emocional com a camada de aplicação :) eles ainda não querem entender ou debater.

    
por 31.01.2018 / 13:19
fonte