Onde colocar a lógica de negócios no design do MVC?

Eu criei um aplicativo Java MVC simples que adiciona registros através de formulários de dados a um banco de dados.

Meu aplicativo coleta dados, também os valida e os armazena. Isso ocorre porque os dados estão sendo obtidos on-line de diferentes usuários. os dados são principalmente de natureza numérica.

Agora, nos dados numéricos que estão sendo armazenados no banco de dados (servidor SQL), desejo que meu aplicativo realize cálculos e exiba os resultados. O usuário não está interessado em como os cálculos são feitos, portanto eles devem ser encapsulados. O usuário deve ser capaz de visualizar apenas os dados computados simples (por exemplo, dados da coluna A menos dados da coluna B divididos por dados da coluna C). Sei como escrever procedimentos armazenados para o mesmo, mas quero um aplicativo de três camadas.

Quero que os dados que eu coloquei no banco de dados como um registro sejam trabalhados executando cálculos nele. Os dados originais devem permanecer inalterados, enquanto os novos dados, pós-cálculos, devem ser armazenados como um novo registro de entidade no banco de dados.

Onde devo escrever o código para este cálculo em segundo plano? Como são as regras e a lógica de negócios, devo colocá-lo em novos arquivos JavaBeans?

— BriskLabs Pakistan
fonte

possível duplicata Ficar OO e Testable ao trabalhar com um banco de dados

— mosquito

Respostas:

A lógica de negócios deve ser colocada no modelo , e devemos ter como objetivo modelos gordos e controladores magros .

Como ponto de partida, devemos começar pela lógica do controlador. Por exemplo: na atualização , seu controlador deve direcionar seu código para o método / serviço que entrega suas alterações no modelo.

No modelo, podemos criar facilmente classes auxiliares / serviços em que as regras ou cálculos de negócios do aplicativo podem ser validados.

Um resumo conceitual

O controlador é para lógica de aplicação. A lógica específica de como seu aplicativo deseja interagir com o "domínio do conhecimento" ao qual ele pertence.
O modelo é para lógica independente do aplicativo . Essa lógica deve ser válida em todas as aplicações possíveis do "domínio do conhecimento" a que pertence.
Portanto, é lógico colocar todas as regras de negócios no modelo.

— EL Yusubov
fonte

resposta clara e concisa agradável ..

— hanzolo 15/05

@Yusubov, por favor, você poderia me explicar a diferença entre a lógica do aplicativo ea lógica de negócios

— Mohamad

@ Oh, em suma, são palavras de efeito para ajudar a descrever camadas de tecnologia em um aplicativo. A lógica de negócios é basicamente regras do sistema, de acordo com as especificações funcionais. Por exemplo, o Objeto A do tipo B deve ter atribuído C e D, mas não E. O Application Logic é mais uma especificação técnica, como usar servlets Java e OJB para persistir em um banco de dados Oracle.

— EL Yusubov

Você poderia elaborar estas palavras:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

Se entendi correto, o artigo mencionado se refere à 'lógica da aplicação' como uma 'lógica de negócios'. Portanto, qualquer coisa que se refira à lógica de negócios não deve ser colocada no controlador ou na exibição.

— EL Yusubov

Como sempre, isso depende da complexidade do projeto.

Em aplicativos triviais, onde a complexidade do modelo de domínio é relativamente pequena, você pode colocar a lógica nos modelos e chamá-la por dia.

No entanto, para aplicativos não triviais com modelos complexos e muitas regras de negócios, é melhor separar as coisas um pouco mais.

Se você colocar a lógica de negócios que envolve mais de um modelo em um modelo, estará introduzindo um forte acoplamento entre esses modelos. À medida que os aplicativos continuam a crescer, esses modelos tendem a se transformar god models, sabendo demais. E isso rapidamente se transforma em uma grande bagunça difícil de testar e manter. Portanto, nesse caso, é benéfico colocar a lógica em uma camada separada.

Ao decidir sobre abstração, sempre leve em consideração a complexidade e os objetivos do seu aplicativo e evite o excesso de engenharia. Para aplicativos triviais / pequenos, a introdução de mais camadas do que precisa aumenta a complexidade, em vez de reduzi-la.

Robert Martin (tio Bob) tem um bom post sobre este assunto: A arquitetura limpa.

— Hakan Deryal
fonte

a pergunta era específica para o MVC. a lógica de negócios deve sempre estar no modelo. O controlador é apenas um adaptador.

— jgauffin

MVC é um dos termos mais sobrecarregados do setor. Eu não quero entrar nas peculiaridades deste termo, pois ele merece um livro. Apenas, o uso do MVC não implica que você deve colocar todas as lógicas nos modelos.

— Hakan Deryal 20/09/12

A partir da definição por Steve Burbeck (equipe Smalltalk):

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Essa é uma definição de adaptador.

— precisa saber é o seguinte

Se você colocar toda a lógica no modelo, você terminará com milhares de linhas de bagunça não sustentável. Esteve lá. Não é pecado ter classes de utilidade e uma camada de serviço.

— asthasr

Eu acho que o que o jgauffin estava dizendo é que a pergunta é específica para o MVC. Se concordarmos em visualizar o sistema da perspectiva do MVC e apenas da perspectiva do MVC, sim, toda a lógica de negócios pertence ao "modelo", mas o "modelo" pode abranger várias classes e camadas, incluindo "classes de utilidade" e "uma camada de serviço". Em outras palavras, não diríamos que a camada de serviço faz parte do controlador ou da visualização, portanto, o melhor ajuste é o modelo.

— DavidS 29/05

Colocar a lógica de negócios dentro do modelo pode parecer o melhor caminho a percorrer. O controlador recebe uma chamada do aplicativo Web remoto. O controlador no serviço da Web MVC atende a chamada e redireciona a execução para um método no BL. Agora, a lógica de negócios pode estar contida no 'Modelo', mas também pode ser posicionada em outra pasta, por exemplo, 'lógica de negócios' . Portanto, não existe uma regra rígida sobre a localização da lógica de negócios.

Estou usando um serviço da Web construído no MVC 3.0 e o contêiner da lógica de negócios é o MVC MODEL .

— Monty Python
fonte

Concordo. Você obtém um aplicativo muito mais flexível quando seu modelo é simplesmente uma estrutura de dados acionada por outras classes de lógica de negócios. Como um exemplo simples, acho que é uma grande falha na abordagem de validação do ASP.NET usando atributos. Se eu anotar a propriedade FirstName de uma Pessoa com o atributo Obrigatório, o que acontece se eu criar uma exibição de administrador em que FirstName não seja necessário? Uma camada de lógica de negócios deve consumir o modelo e determinar as ações apropriadas para ele.

— Xr280xr