Criei um aplicativo MVC Java simples que adiciona registros por meio de formulários de dados a um banco de dados.
Meu aplicativo coleta dados, ele também os valida e armazena. Isso ocorre porque os dados estão sendo obtidos online de diferentes usuários. os dados são principalmente numéricos por natureza.
Agora, sobre os dados numéricos sendo armazenados no banco de dados (servidor SQL), quero que meu aplicativo execute cálculos e exiba os resultados. O usuário não está interessado em como os cálculos são feitos, então eles devem ser encapsulados. O usuário só deve ser capaz de visualizar os dados computados simples (por exemplo, dados da coluna A menos os dados da coluna B divididos pelos dados da coluna C). Sei como escrever procedimentos armazenados para o mesmo, mas quero um aplicativo de três camadas.
Quero os dados que coloquei no banco de dados como um registro, trabalhados executando cálculos nele. Os dados originais não devem ser afetados, 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 de fundo? Como são as regras e a lógica de negócios, devo colocá-los em novos arquivos JavaBeans?
Comentários
- possível duplicata de Permanecendo OO e testável ao trabalhar com um banco de dados
- A lógica de negócios é um apelido para um cara em sua equipe / departamento a quem você pergunta como fazer / operar em um modelo. Por isso ‘ s por que, a lógica de negócios pode ser armazenada em uma classe separada chamada lógica de negócios. O mesmo se aplica à Presentation Logic, que é sinônimo de um designer que responde às suas perguntas sobre como formatar ou exibir os componentes da IU. Também pode haver uma lógica do desenvolvedor (perguntas que você faz e responde por você mesmo ou pergunta aos seus colegas) que representa um conhecimento sobre como criar e conectar os componentes de um programa.
Resposta
A lógica de negócios deve ser colocada no modelo , e devemos buscar modelos gordos e controladores magros >.
Como ponto de partida, devemos começar a partir da 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 auxiliar / classes de serviço onde o aplicativo regras de negócios ou cálculos podem ser validados.
Um conceito resumo
-
O controlador é para a lógica do aplicativo. A lógica específica de como seu aplicativo deseja interagir com o ” domínio de conhecimento ” ao qual pertence.
-
O modelo é para a lógica que é independente do aplicativo . Essa lógica deve ser válida em todas as aplicações possíveis do ” domínio de conhecimento ” ao qual pertence.
-
Portanto, é lógico colocar todas as regras de negócios no modelo.
Comentários
- boa resposta clara e concisa.
- @Yusubov, por favor, você poderia me explicar a diferença entre a lógica do aplicativo e a lógica do negócio
- @Moh, em resumo, essas são palavras da moda para ajudar descrever camadas de tecnologia em um aplicativo. A lógica de negócios é basicamente regras do sistema de acordo com especificações funcionais. Por exemplo, o objeto A do tipo B deve ter atribuído C e D, mas não E. A lógica do aplicativo é mais uma especificação técnica, como usar servlets Java e OJB para persistir em um banco de dados Oracle.
- Por favor explique 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] - Se bem entendi, o artigo mencionado se refere à ‘ lógica do aplicativo ‘ como um ‘ lógica de negócios ‘. Portanto, nada que se refira à lógica de negócios não deve ser colocado no controlador ou na visualização.
Resposta
Como sempre, depende da complexidade do projeto.
Em aplicações triviais, onde a complexidade do modelo de domínio é relativamente pequena, você pode colocar a lógica nos modelos e encerrar o 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, você está introduzindo um forte acoplamento entre esses modelos.À medida que os aplicativos continuam a crescer, esses modelos tendem a se tornar god models, sabendo demais. E isso rapidamente se transforma em uma grande confusão que é difícil de testar e manter. Nesse caso, é benéfico colocar a lógica em uma camada separada.
Ao decidir sobre a abstração, sempre leve em consideração a complexidade e as finalidades do aplicativo e evite engenharia excessiva. Para aplicativos triviais / pequenos, a introdução de mais camadas do que o necessário aumenta a complexidade em vez de reduzi-la.
Robert Martin (Tio Bob) tem uma boa postagem no blog sobre este assunto: A arquitetura limpa.
Comentários
- a pergunta era específica para MVC. a lógica de negócios sempre deve estar no modelo. O controlador é apenas um adaptador.
- MVC é um dos termos mais sobrecarregados da indústria. Eu não ‘ não quero entender as peculiaridades deste termo, pois ele merece um livro. Apenas, usar MVC não ‘ implica que você deve colocar todas as lógicas nos modelos.
- Da definição de 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. - Se você colocar toda a lógica no modelo, vai acabar com milhares de linhas de bagunça insuportável. Esteve lá. Não ‘ é pecado ter classes de utilitários e uma camada de serviço.
- Acho que o que jgauffin queria dizer é que a questão é específica para MVC. Se concordarmos em ver o sistema da perspectiva MVC e apenas da perspectiva MVC, então sim, toda a lógica de negócios pertence ao ” modelo “, mas o ” modelo ” pode abranger várias classes e camadas, incluindo ” classes utilitárias ” e ” uma camada de serviço ” . Colocando de outra forma, não ‘ diríamos que a camada de serviço é uma parte do controlador ou visualização, portanto, o melhor ajuste é o modelo.
Resposta
Colocar a lógica de negócios dentro do modelo pode parecer o melhor caminho a seguir. O controlador recebe uma chamada do aplicativo remoto da web. O controlador no serviço da web MVC recebe 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 alguma outra pasta, digamos, “Lógica de negócios” . Portanto, não há nenhuma regra rígida sobre onde a lógica de negócios estará.
Tenho usado um serviço da web construído em MVC 3.0 e o contêiner de lógica de negócios é o MVC MODELO .
Comentários
- Eu concordo. Você obtém um aplicativo muito mais flexível quando seu modelo é simplesmente uma estrutura de dados aplicada por outras classes de lógica de negócios. Como um exemplo simples, acho que é uma grande falha da abordagem do ASP.NET ‘ para validação usando atributos. Se eu anotar a propriedade FirstName de uma pessoa ‘ s com o atributo Required, o que acontecerá se eu criar uma visualização de administração em que o 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.