Como estruturar a lógica da camada de negócios (aplicativo com lógica de camada de negócios muito complicada, cálculos etc.)

5

Estamos desenvolvendo um aplicativo da Web .NET que usa WebApi . Nós temos camadas separadas:

  • IU (HTML, CSS, js etc.)
  • ApiController - recebe a entrada DTO s da interface do usuário e chama o terminal apropriado na camada de negócios (por exemplo, StudentBLL.Add ou StudentReportBLL.GetFollowReport )
  • Business Layer - contém toda a lógica de negócios; não salva dados diretamente no banco de dados, mas chama o DAL (camada de acesso a dados).
  • Data Access Layer (usa o Entity Framework para CRUD ou, em cenários mais complicados, executa algumas consultas complicadas e assim por diante - ele não tem lógica de negócios).

Além disso:

  1. Usamos "Business Objects" (classes com as quais a EF opera; esses objetos geralmente são transformados em tabelas de banco de dados em nosso banco de dados relacional).
  2. Usamos "Exibir modelos" (usados nos Controllers e também na lógica de negócios).
  3. Usamos o Automapper para mapear Business Objects para View models . Normalmente, o mapeamento é feito em nossa camada de negócios.
  4. Também temos injeção de dependência (todas as classes BLL e DLL possuem interfaces).
  5. Temos Serviços adicionais, como ExcelReader , OurEmailSender , Workflow etc. Não temos problemas com isso.

Até agora, tentamos separar todas as partes lógicas.

Aqui está a definição do problema arquitetônico que enfrento: Está escrito muito sobre questões gerais de arquitetura e como separar camadas. Mas o problema que enfrento é que temos uma grande quantidade de lógica em nossa camada de negócios. Quando começamos a desenvolver esse aplicativo, o código resultou em classes muito grandes de Camada de Negócios com muitos métodos private . Então, começamos a criar Helpers . Isso nos ajudou a limpar um pouco nosso BusinessLayer, mas ainda assim, temos Helpers e algo como " HelpersOfHelpersOfHelpers " muito grande. É claro que muitas vezes o nomeamos de forma diferente, como "Importador" ou "Cálculo" ou "Exportador", mas ainda assim, geralmente são apenas Assistentes com alguns nomes estranhos.

Você pode dar algumas dicas sobre como estruturar a lógica de negócios? Estes podem ser nomes de padrões, algumas sugestões de leitura adicional ou qualquer outra coisa.

    
por renathy 06.04.2017 / 19:05
fonte

2 respostas

2

Você está fazendo a pergunta fundamental da arquitetura: "Eu tenho muita lógica ... como eu a estruturo?" É difícil responder a uma pergunta tão geral em breve, já que vários livros escreveram sobre vários aspectos desse problema.

Mas, em resumo, você provavelmente sofre de "objetos de Deus", e nomes como "XxxHelper" indicam que as classes não têm um propósito claramente definido. É muito mais fácil pensar em um nome significativo se a classe tiver um propósito delimitado e bem definido.

Você precisa começar separando o código em módulos e classes com finalidades claramente definidas. Uma abordagem seria desenhar esboços ou mapas mentais de todas as tarefas e operações na lógica de negócios e tentar agrupá-las em camadas, subsistemas, núcleo, serviços etc. Parece que você já tem esse princípio em baixo para a arquitetura geral, então você precisa aplicar o mesmo processo de design à lógica de negócios.

Os princípios fundamentais de design: Camadas, fatiamento, separação de interesses, responsabilidade única, alto coesão de baixo acoplamento e assim por diante devem ser aplicados em todos os níveis da arquitetura, não apenas no nível superior.

Se você quiser uma abordagem mais formal, você pode procurar em Domain Driven Design , que descreve várias abordagens e padrões para estruturar a lógica de negócios (ou lógica de domínio, como também é chamada, é basicamente a mesma coisa).

    
por 19.05.2017 / 08:58
fonte
0

Muita lógica na sua camada de negócios é um bom problema, é suposto estar lá. Da mesma forma, os métodos privados não são necessariamente um grande problema, desde que o design adequado orientado a objetos seja seguido. O próximo passo seria utilizar princípios orientados a objetos e padrões de design para abstrair e isolar a lógica em unidades fechadas. Padrões de fábrica ou construtor podem ser úteis para importar, e uma maneira possível de isolar cálculos complexos é usar o padrão de estratégia. As coisas importantes para se preocupar são ter muitos métodos estáticos ou classes com muitos métodos públicos que não estão relacionados entre si ou com métodos quase idênticos.

    
por 18.07.2017 / 14:19
fonte