Pode 'mover a lógica de negócios para a camada de aplicação' aumentar o desempenho?

Question

No meu projeto atual, a lógica de negócios é implementada em procedimentos armazenados (a 1000 deles) e agora eles querem aumentá-lo como o negócio está crescendo. Arquitetos decidiram mover a lógica de negócios para camada de aplicação (.net) para aumentar o desempenho e escalabilidade. Mas eles não estão redesenhando / reescrever qualquer coisa. Em suma as mesmas consultas SQL que são disparados de um SP será demitido de uma função .net usando ADO.Net. Como pode este deu qualquer desempenho?

Para o melhor da minha compreensão, precisamos mover a lógica de negócios para a camada de aplicação quando precisamos de independência DB ou há alguma lógica de negócios que pode ser melhor implementada em uma linguagem OOP que um motor RDBMS (como atravessar uma hierarquia ou alguma processamento de imagem, etc ..). No restante dos casos, se não houver nenhuma lógica de negócios complicado de implementar, eu acredito que é melhor para manter a lógica do negócio em si DB, pelo menos, os atrasos de rede entre camada de aplicação e DB podem ser evitados desta forma.

Por favor, deixe-me saber a sua opinião. Eu sou um desenvolvedor olhando algumas decisões de arquitetura com um pouco de hesitação, o perdão a minha ignorância no assunto.

Answer 1

Se a sua lógica de negócios ainda está em instruções SQL, o banco de dados estará fazendo o trabalho tanto quanto antes, e você não vai obter um melhor desempenho. (Pode ser mais trabalho se ele não é capaz de planos de consulta em cache como effectivily como quando foram utilizados procedimentos armazenados)

Para obter um melhor desempenho que você precisa para passar algum trabalho para a camada de aplicação, pode por exemplo, dados de cache no servidor de aplicativos e fazer uma pesquisa ou uma verificação de validação sem bater o banco de dados?

Answer 2

argumentos de arquitectura como esses muitas vezes precisam considerar vários comércios-off, considerando o desempenho em isolamento, ou ideed considerando apenas um aspecto do desempenho, como tempo de resposta tende a perder a imagem maior.

Há claramente alguns trade off entre a execução lógica na camada de banco de dados e envio de parte de trás de dados para a camada applciation e processá-lo lá. os custos do data-navio versus custos de processamento. Como você indicar o custo ea complexidade da lógica de negócios será um fator importante, o tamanho dos dados a serem enviados seria outra.

É concebível, se a camada de DB está a ficar agitado, que o processamento de descarregamento para uma outra camada pode permitir um maior rendimento global, mesmo se o tempo de respostas individuais são aumentadas. Poderíamos então escalar a camada App, a fim de lidar com alguma carga extra. Você agora dizer que o desempenho foi melhorada (maior rendimento global) ou agravado (aumento soem no tempo de resposta).

Agora, considerar se a camada de aplicativo pode implementar estratégias de cache interessantes. Talvez nós temos uma grande vitória desempenho - sem carga no DB em tudo para alguns pedidos

Answer 3

Eu acho que essas decisões não devem ser justificada utilizando dogma arquitetônico. Dados faria muito mais sentido.

Declarações como "Toda a lógica de negócios pertence em procedimentos armazenados" ou "Tudo deve estar na camada intermediária" tendem a ser feitos por pessoas cujo conhecimento é restrito a bancos de dados ou objetos, respectivamente. Melhor combinar tanto quando você julga, e fazê-lo com base em medições.

Por exemplo, se um de seus procedimentos é esmaga um monte de dados e retornar um punhado de resultados, há um argumento que diz que ele deve permanecer no banco de dados. Há pouco sentido em trazer milhões de linhas na memória na camada intermediária, mastigando-os, em seguida, atualizar o banco de dados com outra ida e volta.

Outra consideração é se ou não o banco de dados é compartilhado entre aplicativos. Se assim for, a lógica deve permanecer no banco de dados para que todos possam usá-lo.

tiers Média tendem a ir e vir, mas continua a ser dados para sempre.

Eu sou um objeto cara mim, mas eu gostaria de pisar levemente.

É um problema complicado. Eu não acho que as declarações preto e branco irá funcionar em todos os casos.

Answer 4

Bem como outros já disse, isso depende de muitos fatores. Mas de você questionar parece que os arquitetos estão propondo mover os procedimentos armazenados de dentro DB para SQL dinâmico dentro do aplicativo. Isso soa muito duvidoso para mim. SQL é uma orientada conjunto linguagem e lógica empresarial que requer massageando de grande quantidade de registros de dados seria melhor em SQL. Pense função tipo de pesquisa e relatórios complicado. Nas outras edições de itens de linha de mão com validação de regras de negócios correspondente é muito melhor do que está sendo feito em uma linguagem de programação. Cache de dados em mudança lenta na camada aplicativo é outra vantagem. Este é ainda melhor se você tem dedicado serviço de camada intermediária que funciona como uma porta de entrada para todos os dados. Se os dados são compartilhados diretamente entre aplicativos diferentes, em seguida, proc armazenado pode ser uma boa idéia. Você também tem que fator a disponibilidade / experiência de talento SQL vs talento de programação na organização. Não é a resposta realmente não geral para esta questão.