Onde mover a lógica de negócios ao movê-lo para fora do banco de dados

Question

Tenho uma aplicação ASP.NET CRUD-pesado com toda a lógica de negócios em procedimentos armazenados.

Como exemplo, há um procedimento de actualização armazenado que de ~ 500 linhas de comprimento e contém grandes quantidades de lógica condicional, fazendo referência a várias tabelas e UDFs. O proc leva no nome do campo a ser actualizado eo novo valor, define um monte de variáveis ??declaradas, faz um monte de validação e cria uma instrução SQL dinâmica para fazer a atualização. Uma vez size fits all. É grande e confuso.

Eu gostaria de mudar a lógica de negócios para o lado do .NET para torná-lo mais fácil de gerenciar / atualizar, testar e colocar sob controle de origem.

A minha pergunta é: onde deve essa lógica de negócios go?

Say Eu tenho um objeto PurchaseOrder com uma propriedade chamada 'Factory'. Se a fábrica fica alterado, eu preciso certificar-se da nova fábrica atribuído torna o produto que está no PurchaseOrder, que tem preço, e que há uma quantidade mínima pedida com base nessa fábrica, etc. Todas essas validações exigem consultas na banco de dados.

Eu deveria ter Fábrica do objeto PurchaseOrder setter ser responsável por fazer a validação de dados através de um 'isFactoryValid' método / propriedade que faz com que as várias chamadas para um objeto de acesso de dados genéricos, em seguida, fazer a atualização se for?

Ou faço para criar um banco de dados objeto PurchaseOrder / 'proxy' que é responsável por tratar apenas acesso a dados PurchaseOrder-relacionado. Neste caso, eu teria um método de 'isFactoryValid' no proxy que é chamada por setter do PurchaseOrder e, em seguida, uma chamada ao método de atualização do proxy?

Como posso determinar se eu precisa se preocupar em aumentar o tráfego para o banco de dados com todas essas chamadas extras?

Answer 1

Existem dois principais padrões que são amplamente utilizados para implementar persistência lógica fora do DB:

• ActiveRecord Padrão -. Persistência lógica é em seu objeto de domínio
• Pattern Repository - objeto ou camada separada lida com um acesso de dados - o seu "proxy" conceito endereços isso.

O truque com os dois objetos é saber quando fazer uma viagem para o banco de dados e saber quando não . Por exemplo, há irá ser validações redundantes que serão feitas entre a DB e a camada de domínio, por exemplo, mesmo antes de tomar uma DB chamar você deve avaliar para valores não nulos, cordas truncar comprimento, etc . Somente após estas verificações foram feitas deve ser feita uma chamada para Salvar no db.

Há também uma ampla gama de estratégias disponíveis para aumentar o desempenho ou minimizar viagens de banco de dados, como carregamento lento, transações, e similares.

Answer 2

Uma maneira de fazê-lo: Você tem uma camada de dados no .net (uma ou várias classes de dados) com uma interface para a camada ... então você tem uma camada de negócio que executa a lógica de negócios usando a interface. http://en.wikipedia.org/wiki/Multitier_architecture

Answer 3

Você também pode transformar sua lógica de negócio em pedaços de serviços web reutilizáveis. WCF fornece grande suporte de ferramentas.

Answer 4

Olhe em Domain Driven Design (DDD), que irá responder a algumas das suas perguntas. Ele fala sobre Repositoryies para acesso a dados e especificação validações. Um bom ORM também ajudaria. Este livro também é grande:

alt texto http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7 .jpg

Answer 5

Isso vai depender do modelo de objeto que você criou e como você deixar o seu interlocutor decidir qual fábrica será a nova fábrica para processar o PurchaseOrder.

Por exemplo, se você der o seu interlocutor uma lista de Fábricas eles podem escolher, você pode filtrar a lista para apenas aqueles que apoiam o produto associado com o PurchaseOrder existente (eu estou supondo que você está editado um pedido existente) . Se você quer ter a validar PurchaseOrder que a fábrica pode processar o pedido, eu teria o setter na chamada PurchaseOrder um método na Fábrica (algo como CanProcessOrderFor (produto, quantidade)).

Eu estou supondo que você terá tido para fazer uma consulta de banco de dados já para obter a lista de fábricas ea PurchaseOrder. Eu teria a consulta para a Fábrica de objetos retornar a sua lista de produtos suportados e quantidades correntes (ou ordem mínima - independentemente das suas necessidades lógicas para ser).

Um bom ORM como NHibernate vai deixar você armazenar em cache alguns destes resultados para minimizar roundtrips se este é um cenário comum.