Como dividir uma camada de objeto da camada de dados e de negócios, quais são os deveres apropriados de cada um?

Question

Se houvesse uma linha de aplicativos de negócios em camadas como esta, isso seria uma adequada divisão do trabalho:

Acesso a Dados

• Invoca única procedimentos armazenados, mapeia propriedades de DTO s para um tablse de hash que são usados ??para coleções de parâmetros de preenchimento ADO.NET comando.

• Apenas conjunto com referência à SqlDataClient.

• Significativo negociação lógica com que meios em branco, nulo e vazio no código de mapeamento, mas outro sábio nenhuma lógica de validação ou outro domínio específico.

So-Called Business Logic

• divide vários conjuntos de resultados em tabelas de dados individuais, por exemplo,

  ReturnNthRecordSetFromStoredProcFoo public void ()

• passar para acesso a dados para conjuntos de dados, por exemplo.

  ReturnDataSet public void (string name) { retorno (novo PersonController) .GetAnotherDataSet (nome);}

• mapeia uma linha de uma DataTable a um DTO s

• Significativo negociação lógica com que meios em branco, nulo e vazio no código de mapeamento.
• Mantém objeto de transação, embora seja usado exclusivamente para embrulhar chamadas de procedimento armazenado único.
• não tem uma referência a SqlDataClient, por isso não pode usar SqlDataReaders para preencher DTOs
• Nenhuma referência para System.Web.UI
• As regras de autorização, mas caso contrário nenhuma lógica específica de domínio.

UI

• 2 modo como os dados de ligação do DTO para formas ASP.NET.
• Validação de propriedades de Controles de validação geralmente não directamente contra DTO
• "Coleções" são navegado por DataSets de ligação às redes. Na verdade tentar fazer qualquer coisa com coleções requer a UI para interagir sobre DataRows em tabelas de dados e saber quais são os nomes das colunas apropriadas (que são geralmente só tipo-de-similar aos DTOs)

Portanto, a questão, finally-- com esta aplicação, se o Data Access Layer assumir os deveres da camada de negócios chamada ser fundidos? Não é este já uma camada dois, ( quase um!) aplicativo, exceto para a inconveniência de um conjunto extra?

Informações adicionais: Ok, já sei que o servidor de aplicativos será uma máquina, provavelmente para sempre, uma vez que é um aplicativo intranet low-user-contagem. Então eu sei que não projetar para camadas de aplicações fisicamente separados. Além disso, ele provavelmente só irá apoiar um UI e ser inteiramente descartado se alguma vez precisar de suporte algo diferente de ASP.NET-- outra razão oft cotado para Tiers / camadas.

Answer 1

Parece-me que a responsabilidade entre os níveis é um pouco confusa. A camada de dados parece bastante normal. A ( "chamado") camada de negócios é o lugar onde as coisas ficam confusas.

Algumas reflexões sobre a camada de negócios:

• Parece haver uma grande quantidade de representações de dados. Você menciona tabelas de dados, conjuntos de dados, transferência de dados objetos. A abordagem padrão em todo o aplicativo seria melhor.

• métodos camada de negócios com nomes como ReturnNthRecordSetFromStoredProcFoo e ReturnDataSet não são significativos e não fornecem um nível adequado de abstração para serviços de negócios. (Talvez aqueles eram apenas exemplos mal escolhidos não da aplicação?)

• Normalmente, uma camada de negócios iria fornecer mais do que um DataSet passar. Em vez de lidar com mapeamentos, nulos etc. a camada de negócios deve se concentrar na validação, regras de negócios, segurança, e talvez até mesmo de auditoria (embora alguns preferem fazer isso no banco de dados).

• Mesmo que a camada de negócios só é invocando um único procedimento armazenado, eu não tenho nenhum problema com o controle de transação na camada de negócios. camada de negócios deve controlar a transação para que vários objetos de dados podem participar na mesma transação (que poderia até mesmo ser em diferentes bancos de dados). Mesmo que haja apenas uma chamada agora, se você precisar adicionar mais chamadas no futuro isso vai ser fácil e não vai resultar em reequipamento controle de transação em sua aplicação.

• Eu acho que as dependências estão OK -. Nenhuma referência ao Web.UI ou SQLClient da camada de negócios

• As regras de autorização são também OK. Eu iria expandir para incluir segurança e não apenas de autorização. Além disso, não vejo qualquer lógica em qualquer negócio - apenas curioso, se a lógica de negócios está nos procedimentos armazenados? Se eu ia adivinhar, eu diria que sim, uma vez que cada método de negócio invoca apenas um procedimento armazenado. Se assim for, então isso é um grande não, não para mim.

Eu não iria combinar as camadas de negócios e dados. Eu prefiro manter a camada de lógica de negócios ea camada de acesso de dados separado. Dada a escolha entre combinando-os e tentando separar as responsabilidades de um pouco mais eu inclinar-se para o último.

No entanto, vendo como se este é um aplicativo existente com questões que eu levaria um ponto mais pragmática de vista. Tudo vem com um custo e é importante para determinar quais alterações estão sendo feitas, o que é o esforço eo risco das mudanças, o que é o real benefício das mudanças, e como as mudanças terão impacto sobre do ciclo de ensaio.

Algumas outras questões para pensar são: quais são as principais questões que você deseja endereço? eles são funcionais (por exemplo, erros, falta de estabilidade)? Ou desempenho relacionado? Ou é arquitetura? Ou talvez relacionado com manutenção - você precisa adicionar uma nova funcionalidade, mas estão encontrando dificuldades? Você tem um prazo ou um orçamento? Se você puder responder a algumas dessas perguntas pode ajudar a guiá-lo.

Answer 2

Dependendo da sua carga do servidor deve determinar o número de camadas físicas. O número de camadas lógicas é realmente mais de uma escolha pessoal.

Em nossa organização nós usamos a CSLA quadro . É um quadro objeto de negócios que se esforça para tornar rico, databound UIs simples de usar e manter, ao mesmo tempo dando flexibilidade na camada de dados.

Eu não vou entrar em muitos profundidade aqui como seria melhor para você determinar por si mesmo se o quadro vale a pena para você usar, mas escusado será dizer, ele tem sua própria classe SafeDataReader que responde por valores nulos, eliminando a necessidade de conjuntos de dados de uso.

Sua " dataportal " (artigo é mais velhos, mas ainda relevante) permite mover facilmente o acesso a dados para sua própria camada com muito pouco esforço e nenhuma mudança de código.

DNRtv tem alguns moldes de vídeo pod em que o designer de CSLA, Rockford Lhotka, mostra o funcionamento do a aplicação da amostra. Parte 1 e Parte 2 .

Os shows são apenas uma hora cada e provavelmente pode ajudá-lo a decidir se é a coisa certa para você usar.

Answer 3

Eu esperaria para ver o que você descreve como sua camada de negócios como tipo de camada de dados material. Eu espero que a minha camada de dados iria me proteger de ter que se preocupar com valores nulos e tais coisas. Eu também espero que minha camada de negócios deve conter regras de negócios e conceitos que são mais abstrato. Por exemplo, se um "Grupo" é uma coleção de "Usuário" é que eu gostaria de ver funções do tipo de negócio para manipular esses usuários como parte de um grupo de alto nível. Por exemplo, talvez uma função que iria atribuir permissões a todos os membros desse grupo ou permitir que o nível da interface do usuário para aplicar políticas para esses usuários como membros de um grupo. Eu não espero para ver funções que tentam esconder o fato de que todos eles vieram de um banco de dados. Espero que este seja útil.