A lógica de negócios: Banco de Dados ou Camada de Aplicação

https://stackoverflow.com/questions/119540

02-07-2019
|

Pergunta

A velha pergunta. Onde você deve colocar sua lógica de negócio, no banco de dados como procedimentos armazenados (ou pacotes), ou no aplicativo / camada intermediária? E mais importante, por quê?

Suponha que a independência do banco de dados não é um objetivo.

Solução

suficiente Coloque a lógica de negócios no banco de dados para garantir que os dados são consistentes e corretas.

Mas não temem ter que duplicar alguns dos essa lógica em outro nível para melhorar a experiência do usuário.

Outras dicas

manutenção do seu código é sempre uma grande preocupação quando se determina onde a lógica de negócios deve ir.

Integrado depuração ferramentas e IDEs mais poderosas geralmente fazem manutenção de código camada intermediária mais fácil do que o mesmo código em um procedimento armazenado. A menos que haja um motivo real de outra forma, você deve começar com a lógica de negócios em sua camada / aplicação meio e não em procedimentos armazenados.

No entanto, quando você vem para relatórios e mineração de dados / pesquisa, procedimentos armazenados podem muitas vezes uma escolha melhor. Isso é graças ao poder dos bancos de dados de agregação / filtrando capacidades eo fato de que você está mantendo o processamento muito perto da fonte dos dados. Mas isso pode não ser o que a maioria considera a lógica de negócios clássico de qualquer maneira.

Para casos muito simples que você pode colocar sua lógica de negócios em procedimentos armazenados. Normalmente, até mesmo os casos simples tendem a ficar complicado ao longo do tempo. Aqui estão as razões eu não colocar lógica de negócios no banco de dados:

Colocar a lógica de negócios no banco de dados firmemente casais de TI para a implementação técnica do banco de dados. Alterar uma tabela fará com que você mudar um monte dos procedimentos armazenados novamente causando uma série de erros extras e testes extra.

Normalmente, a interface do usuário depende de lógica de negócios para coisas como validação. Colocar essas coisas no banco de dados fará com acoplamento forte entre o banco de dados e interface do usuário ou em diferentes casos duplica a lógica de validação entre os dois.

Ele vai ficar difícil ter múltiplas aplicações de trabalho no mesmo banco de dados. Mudanças para uma aplicação fará com que os outros a quebrar. Isto pode rapidamente se transformar em um pesadelo de manutenção. Então, ele realmente não escala.

Mais praticamente SQL não é uma boa linguagem para implementar a lógica de negócios de uma forma compreensível. SQL é ótimo para operações de conjunto baseado mas perde construções para "programação no grande" é difícil de manter grandes quantidades de procedimentos armazenados. linguagens OO modernos são mais adequadas e mais flexível para isso.

Isto não significa que você não pode usar procedimentos armazenados e vistas. Eu acho que às vezes é uma boa idéia de colocar uma camada extra de procedimentos armazenados e pontos de vista entre as mesas e aplicativo (s) de dissociar os dois. Dessa forma, você pode alterar o layout do banco de dados sem alterar interface externa permitindo que você refatorar o banco de dados de forma independente.

É realmente até você, enquanto você está consistente .

Uma boa razão para colocá-lo em sua camada de banco de dados: se você tem certeza de que seus clientes nunca vai mudar seu banco de dados back-end.

Uma boa razão para colocá-lo na camada de aplicação:. Se você está direcionando várias tecnologias de persistência para sua aplicação

Você também deve levar em conta as competências do núcleo. São seus desenvolvedores principalmente desenvolvedores camada de aplicação, ou são principalmente DBA-tipos?

Embora existam certamente beneficia a ter a lógica de negócios na camada de aplicação, eu gostaria de salientar que as línguas / enquadramentos parecem mudar com mais freqüência, em seguida, os bancos de dados.

Alguns dos sistemas que suportam, passou pelos seguintes UIs nos últimos 10-15 anos: Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet. A única coisa que não mudou -. Base de dados relacional e procedimentos armazenados

Enquanto não há uma resposta certa - isso depende do projeto em questão, eu recomendaria a abordagem defendida em " Domain Driven Desig n" por Eric Evans. Nesta abordagem a lógica do negócio é isolado em sua própria camada - camada de domínio - que fica no topo da camada de infra-estrutura (s) - que poderia incluir o seu código de banco de dados, e abaixo da camada de aplicação, que envia os pedidos para a camada de domínio para a realização e escutas para confirmação da sua conclusão, eficazmente dirigir a aplicação.

Desta forma, a lógica do negócio é capturado em um modelo que pode ser discutido com quem entende do negócio, além de questões técnicas, e deve tornar mais fácil a mudanças isoladas nas regras de negócios próprios, as questões de implementação técnica, e o fluxo da aplicação que interage com o modelo de negócio (domínio).

Eu recomendo a leitura do livro acima, se você tem a chance, pois é muito bom em explicar como isso ideal pura pode realmente ser aproximada no mundo real de código real e projetos.

independência de banco de dados, que o questionador exclui como uma consideração neste caso, é o argumento mais forte para tomar a lógica do banco de dados. O argumento mais forte para a independência do banco de dados é para a capacidade de software vender para empresas com sua própria preferência para um backend de banco de dados.

Por isso, eu considero o principal argumento para a tomada de procedimentos armazenados fora do banco de dados para ser apenas um comercial, não um técnico. Pode haver razões técnicas, mas também há razões técnicas para mantê-lo lá -. Desempenho, integridade e a capacidade de permitir que vários aplicativos para usar a mesma API, por exemplo

Se deve ou não usar SP também é fortemente influenciada pela base de dados que você está indo para uso. Se você tomar a independência do banco de dados fora de consideração, então você vai ter experiências muito diferentes usando T-SQL ou utilizando PL / SQL.

Se você estiver usando o Oracle para desenvolver um aplicativo, em seguida, PL / SQL é uma escolha óbvia como uma linguagem. É é muito intimamente ligado com os dados, continuamente melhorados em cada relase e qualquer ferramenta de desenvolvimento decente vai desenvolvimento integratePL / SQL com o CVS ou Subversion ou algo assim.

ambiente de desenvolvimento Application Express baseado na web da Oracle é ainda construída de 100% com PL / SQL.

Qualquer coisa que afete a integridade dos dados deve ser colocado no nível de banco de dados. Outras coisas além da interface com o usuário, muitas vezes colocar dados em, atualizar ou Apagar dados da base de dados, incluindo as importações, atualizações em massa para mudar um esquema de preços, hot fixes, etc. Se você precisa para garantir as regras são sempre seguidos, colocar a lógica da inadimplência e gatilhos.

Isto não quer dizer que não é uma boa idéia para também tê-lo na interface do usuário (por que se preocupar envio de informações de que o banco de dados não aceitará), mas a ignorar essas coisas no banco de dados é um desastre tribunal .

Se precisar de independência de banco de dados, você provavelmente vai querer colocar toda a lógica o seu negócio na camada de aplicação, desde os padrões disponíveis na camada de aplicativo são muito mais prevalente do que aqueles disponíveis para a camada de banco de dados.

No entanto, se a independência do banco de dados não é o fator nº 1 eo conjunto de habilidades de sua equipe inclui habilidades de banco de dados fortes, em seguida, colocar a lógica de negócios no banco de dados pode vir a ser a melhor solução. Você pode ter seus folks aplicação fazendo coisas específicas de aplicativos e seus pais de banco de dados para garantir que todos as consultas voar.

É claro que há uma grande diferença entre ser capaz de jogar uma instrução SQL juntos e ter "habilidades de banco de dados fortes" - se sua equipe está mais perto do primeiro do que o último, em seguida, colocar a lógica no aplicativo usando um dos hiberna deste mundo (ou alterar a sua equipa!).

Na minha experiência, em um ambiente empresarial você terá um banco de dados único alvo e habilidades nesta área - neste caso, colocar tudo o que puder no banco de dados. Se você está no negócio de venda de software, os custos de licença de banco de dados fará com que a independência do banco de dados o fator mais importante e você será implementar tudo o que puder na camada de aplicativo.

Espero que ajude.

É hoje possível submeter à subversão seu código proc armazenado e para depurar esse código com um bom suporte de ferramentas.

Se você usar procedimentos armazenados que combinam instruções SQL que você pode reduzir a quantidade de tráfego de dados entre o aplicativo eo banco de dados e reduzir o número de chamadas de banco de dados e obter grandes ganhos de desempenho.

Uma vez que começamos a construir em C # nós tomamos a decisão de não usar procedimentos armazenados, mas agora estamos nos movendo mais e mais código para procedimentos armazenados. Especialmente processamento em lote.

No entanto, não usar gatilhos, uso armazenados procs ou melhores pacotes. Gatilhos fazer diminuição de manutenção.

Colocar o código na camada de aplicação irá resultar em uma aplicação independente DB.

Às vezes é melhor usar procedimentos armazenados por motivos de desempenho.

It (como de costume) depende dos requisitos da aplicação.

A única coisa que vai em um banco de dados é de dados.

Os procedimentos armazenados são um pesadelo de manutenção. Eles não são dados e eles não pertencem ao banco de dados. A coordenação interminável entre desenvolvedores e DBAs é pouco mais do que o atrito organizacional.

É difícil manter um bom controle de versão sobre procedimentos armazenados. O código de fora do banco de dados é muito fácil de instalar - quando você pensa que você tem a versão errada você acabou de fazer um SVN UP (talvez uma instalação) e costas de seu aplicativo para um estado conhecido. Você tem variáveis ??de ambiente, links de diretórios, e os lotes de controle ambiental sobre a aplicação.

Você pode, com manipulações PATH simples, tem software variante disponível para situações diferentes (melhorias, teste, QA, produção, específicas do cliente-formação, etc., etc.)

O código dentro do banco de dados, no entanto, é muito mais difícil de gerir. Não há ambiente adequado - não "PATH", links de diretório ou outras variáveis ??de ambiente - para fornecer qualquer controle utilizável sobre o software está sendo usado; você tem um conjunto permanente, globalmente consolidado de software de aplicação preso no banco de dados, casada com os dados.

Os gatilhos são ainda piores. Eles são tanto uma manutenção e um pesadelo de depuração. Não vejo qual o problema que eles resolvem; eles parecem ser uma forma de trabalhar aplicações em torno de mal-concebidas em que alguém não podia ser incomodado para usar as classes disponíveis (ou bibliotecas de funções) corretamente.

Enquanto algumas pessoas acham o argumento desempenho convincente, eu ainda não vi dados de referência suficientes para me convencer de que procedimentos armazenados são todos tão rápido. Todo mundo tem uma anedota, mas ninguém tem side-by-side código onde os algoritmos são mais ou menos o mesmo.

[Nos exemplos que eu vi, o aplicativo antigo era uma bagunça mal concebidos; quando os procedimentos armazenados foram escrito, a aplicação foi re-arquitectados. Eu acho que a mudança de design teve mais impacto do que a mudança de plataforma.]

A lógica de negócios deve ser colocado na camada de aplicativo / médio como uma primeira escolha. Dessa forma, ele pode ser expressa na forma de um modelo de domínio, ser colocado no controle de origem, ser divididos ou combinados com código relacionado (reformulado), etc. Ele também lhe dá alguma independência de fornecedor de banco de dados.

Object Oriented línguas também são muito mais expressiva do que procedimentos armazenados, permitindo-lhe melhor e mais facilmente descrever em código que deveria estar acontecendo.

A única boa razões para colocar código em procedimentos armazenados são: se isso produz um benefício significativo e necessário desempenho ou se as mesmas necessidades de código de negócio para ser executado por várias plataformas (Java, C #, PHP). Mesmo quando se utiliza múltiplas plataformas, existem alternativas tais como web-services que poderia ser mais adequado para compartilhar funcionalidade.

A resposta em minha experiência, está em algum lugar em um espectro de valores geralmente determinada por onde as habilidades da sua organização mentir.

O DBMS é uma besta muito poderosa, o que significa o tratamento adequado ou inadequado trará grande benefício ou grande perigo. Infelizmente, em muitas organizações, a atenção primária é pago ao pessoal de programação; habilidades DBMS, especialmente consulta Desenvolvimento de Competências (em oposição a administrativa) são negligenciados. O que é agravado pelo fato de que a capacidade de avaliar as habilidades de DBMS também está provavelmente ausente.

E há poucos programadores que suficientemente entender o que eles não entendem sobre bancos de dados.

Daí a popularidade dos conceitos abaixo do ideal, como o Active Records e LINQ (para jogar em algum viés óbvio). Mas eles são, provavelmente, a melhor resposta para essas organizações.

No entanto, nota que as organizações altamente escala tendem a pagar muito mais atenção para o uso eficaz de armazenamento de dados.

Não há resposta certa independente para esta pergunta. Depende das exigências da sua aplicação, as preferências e habilidades de seus desenvolvedores, e a fase da lua.

A lógica de negócios é para ser colocado na camada de aplicativo e não no banco de dados. A razão é que um procedimento de banco de dados armazenado é sempre dependen no produto de banco de dados que você usa. Esta quebra das vantagens do modelo de três camadas. Você não pode facilmente mudar para um outro banco de dados, a menos que você fornecer um procedimento armazenado extra para este produto de banco de dados. por outro lado, às vezes, faz sentido colocar lógica em um procedimento armazenado para otimização de desempenho.

O que eu quero dizer é a lógica de negócios deve ser colocado na camada de aplicativo, mas há exceções (principalmente motivos de desempenho)

aplicação Bussiness 'camadas' são:

1. User Interface

Este implementos vista do utilizador de negócio de h (é / er) trabalho. Ele usa termos que o usuário está familiarizado.

2. Processamento

Este é o lugar onde os cálculos e manipulação de dados acontecer. Qualquer lógica de negócios que envolve a alteração de dados são implementadas aqui.

3. Banco de dados

Esta poderia ser: um banco de dados sequencial normalizado (o-SQL com base DBMS do padrão); um OO-banco de dados, armazenamento de objetos que envolvem o negócio de dados; etc.

O que vai Onde

No chegar às camadas acima que você precisa para fazer a análise e desenho necessário. Isto indicaria que a lógica do negócio seria melhor ser implementado: regras de integridade de dados e questões de concorrência / em tempo real a respeito de dados atualizações normalmente seria implementado como perto dos dados quanto possível, mesmo que seria calculado campos, e este é um ponteiro bom para armazenados-procedures / triggers, em que é absolutamente necessário de dados de integridade e transação-controle.

O negócio de regras que envolvem o significado e uso dos dados que na maioria das vezes ser implementado na camada de processamento, mas também aparecem na Interface do Usuário como fluxo de trabalho do usuário - que liga a vários processos em alguma seqüência que reflete o trabalho do usuário.

Imho. há duas preocupações conflitantes com decidir onde lógica de negócios vai em um aplicativo orientado a banco de dados relacional:

manutenção
confiabilidade

Re. manutenção:. Para permitir o desenvolvimento futuro eficiente, lógica de negócios pertence à parte do seu aplicativo que é mais fácil de depurar e controle de versão

Re. confiabilidade: Quando há um risco significativo de inconsistência, lógica de negócios pertence à camada de banco de dados. Bancos de dados relacionais pode ser concebida para verificar se há restrições sobre os dados, por exemplo não permitir valores nulos em colunas específicas, etc. Quando um cenário surge em seu design do aplicativo, onde haja necessidades de dados para estar em um estado específico que é demasiado complexo para expressar com estas restrições simples, ele pode fazer sentido usar um gatilho ou algo semelhante na camada de banco de dados.

Triggers são uma dor de manter-se atualizado, especialmente quando a sua aplicação deve ser executado em sistemas clientes que nem sequer têm acesso também. Mas isso não significa que é impossível mantê-las ou atualizá-las. Os argumentos de S. Lott em sua resposta que é uma dor e um aborrecimento são completamente válido, eu vou segundo que e foram lá também. Mas se você manter essas limitações em mente quando você projetar sua camada de dados e se abster de utilizar gatilhos e funções para nada, mas as necessidades absolutas é administrável.

Em nossa aplicação, mais lógica de negócios está contida na camada do modelo da aplicação, por exemplo, uma factura sabe como inicializar-se a partir de uma dada ordem de venda. Quando um monte de coisas diferentes são modificados sequencialmente para um conjunto complexo de mudanças como este, nós enrolá-las em uma transação para manter a consistência, ao invés de optar por um procedimento armazenado. Cálculo dos totais etc. são todos feitos com métodos na camada modelo. Mas quando precisamos desnormalizar algo para desempenho ou inserir dados em uma tabela 'mudanças' utilizado por todos os clientes para descobrir quais objetos eles precisam para expirar em seu cache de sessão, usamos gatilhos / funções na camada de banco de dados para inserir uma nova linha e enviar uma notificação (Postgres escutar / notificar coisas) a partir deste gatilho.

Depois de ter a nossa aplicação no campo por cerca de um ano, usado por centenas de clientes todos os dias, a única coisa que eu mudaria se tivéssemos que começar do zero seria para projetar nosso sistema para a criação de funções de banco de dados (ou procedimentos armazenados , porém você quiser chamá-los) com versões e atualizações para eles em mente a partir do get-go.

Felizmente, nós temos algum sistema em prática para manter o controle de versões de esquema, então nós construímos algo em cima do que para cuidar de substituir as funções de banco de dados. Teria salvou-nos algum tempo se tivéssemos considerado a necessidade de substituí-los desde o começo embora.

Claro, tudo muda quando você pisa fora do reino de RDBMS de em sistemas de tupla de armazenamento como a Amazon SimpleDB e BigTable do Google. Mas isso é uma história diferente:)

Nós colocamos um monte de lógica de negócios em procedimentos armazenados - não é ideal, mas muitas vezes é um bom equilíbrio entre desempenho e confiabilidade.

E nós sabemos onde é, sem ter que procurar por acres de soluções e base de código!

A escalabilidade é também fator muito importante para pusing lógica de negócios na camada do meio ou aplicativo do que layer.It banco de dados deve ser entendido que DatabaseLayer é apenas para interagir com banco de dados não manipular, que é devolvido para ou a partir do banco de dados.

Lembro de ter lido um artigo em algum lugar que assinalou que muito bem tudo o que pode ser, em algum nível, parte da lógica de negócios, e por isso a pergunta não tem sentido.

Eu acho que o exemplo dado foi a exibição de uma factura na tela. A decisão de marcar um um atraso no vermelho é uma decisão de negócios ...

É um continuum. IMHO o fator mais importante é a velocidade. Como u pode obter este otário a funcionar o mais rapidamente possível, enquanto ainda aderir a bons inquilinos de programação tais como manutenção, desempenho, escalabilidade, segurança, confiabilidade etc. Muitas vezes SQL é a forma mais concisa para expressar algo e também passa a ser os mais perfeita muitas vezes, com exceção das operações de cordas etc, mas é aí que o seu CLR Procs pode ajudar. A minha convicção é a lógica de negócios liberalmente polvilhe em torno de onde quer que você sente que é melhor para a empresa na mão. Se você tem um monte de desenvolvedores de aplicativos que merda suas calças quando se olha para SQL, em seguida, deixá-los usar a sua lógica aplicativo. Se você realmente deseja criar um aplicativo de alto desempenho com grandes conjuntos de dados, colocar o máximo de lógica no DB como você pode. Demita seu DBA e dar aos desenvolvedores a liberdade total sobre suas bases de dados Dev. Não há uma resposta ou melhor ferramenta para o trabalho. Você tem várias ferramentas para se tornar perito em todos os níveis da aplicação e em breve você vai achar que você está gastando muito mais tempo escrevendo agradável consise expressiva SQL sempre que se justifique e usando a camada de aplicação outras vezes. Para mim, em última análise, reduzir o número de linhas de código é o que leva à simplicidade. Acabamos convertido uma aplicação rica sql com apenas 2.500 linhas de código do aplicativo e 1000 linhas de SQL para um modelo de domínio que agora tem 15500 linhas de código do aplicativo e 2500 linhas de SQL para alcançar o que o ex-aplicativo rico sql fez. Se você pode justificar um aumento de 6 vezes no código como "simplificado", em seguida, vá em frente.

Esta é uma grande questão! Achei isso depois que eu já tinha pedido um simliar questão , mas isso é mais específico. Ele surgiu como resultado de uma decisão alteração de design que eu não estava envolvido na tomada.

Basicamente, o que me foi dito foi que, se você tem milhões de linhas de dados em suas tabelas de banco de dados, em seguida olhar para colocar a lógica de negócios em procedimentos armazenados e gatilhos. Isso é o que estamos fazendo agora, convertendo um aplicativo java em procedimentos armazenados para manutenção como o código Java tornou-se complicado.

Eu encontrei este artigo em: a lógica de negócios Guerras O autor também fez as linhas milhão em uma discussão de mesa, que eu achei interessante. Ele também acrescentou lógica de negócios em javascript, que é do lado do cliente e fora da camada de lógica de negócios. Eu não tinha pensado sobre isso antes mesmo que eu usei javascript para validação por anos, para juntamente com a validação do lado do servidor.

A minha opinião é que você quer a lógica de negócios na aplicação / camada intermediária como uma regra de ouro, mas fazê casos não desconto em que faz sentido para colocá-lo no banco de dados.

Um último ponto, há um outro grupo onde eu estou trabalhando atualmente que está fazendo um trabalho enorme banco de dados para a pesquisa e a quantidade de dados que estão a tratar é imensa. Ainda assim, para que eles não têm qualquer lógica de negócios no próprio banco de dados, mas mantê-lo na aplicação / camada intermediária. Para sua concepção, a aplicação / camada intermediária era o lugar correto para isso, então eu não usaria o tamanho das tabelas como a única consideração design.

lógica

O negócio é geralmente incorporada por objetos, e as várias construções de linguagem de encapsulamento, herança e polimorfismo e. Por exemplo, se um aplicativo bancário está passando em torno do dinheiro, pode haver um tipo de dinheiro que define os elementos de negócios do que o "dinheiro" é. Este, em vez de usar um decimal primitivo para representar dinheiro. Por esta razão, OOP bem concebido é o lugar onde a "lógica de negócios" vida-não estritamente em qualquer camada.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow