Lógica de negócios no MVC [fechado]

Eu tenho 2 perguntas:

Q1 Onde exatamente a "lógica de negócios" está no padrão MVC? Estou confuso entre modelo e controlador.

Q2 "Lógica de negócios" é o mesmo que "Regras de negócios"? Se não, qual é a diferença?

Seria ótimo se você pudesse explicar com um pequeno exemplo.

As regras de negócios seguem o modelo.

Digamos que você estivesse exibindo emails para uma lista de emails. O usuário clica no botão "excluir" ao lado de um dos e-mails, o controlador notifica o modelo para excluir a entrada N e, em seguida, notifica a visualização que o modelo mudou.

Talvez o email do administrador nunca deva ser removido da lista. Essa é uma regra de negócios, esse conhecimento pertence ao modelo. A visualização pode finalmente representar essa regra de alguma forma - talvez o modelo exponha uma propriedade "IsDeletable" que seja uma função da regra de negócios, de modo que o botão excluir na visualização seja desativado para determinadas entradas - mas a própria regra não esteja contida na vista.

O modelo é finalmente o gatekeeper para seus dados. Você deve poder testar sua lógica de negócios sem tocar na interface do usuário.

Primeiro de tudo:
acredito que você está misturando o padrão MVC e os princípios de design baseados em n camadas.

Usar uma abordagem MVC não significa que você não deve estratificar seu aplicativo.
Pode ajudar se você vê o MVC mais como uma extensão da camada de apresentação.

Se você inserir código de não apresentação dentro do padrão MVC, poderá acabar em breve com um design complicado.
Portanto, sugiro que você coloque sua lógica de negócios em uma camada de negócios separada.

Basta dar uma olhada no seguinte: Artigo da Wikipedia sobre arquitetura de várias camadas

Ele diz:

Hoje, o MVC e o MVP (Model-View-Presenter) similar são padrões de design de Separação de Preocupações que se aplicam exclusivamente à camada de apresentação de um sistema maior.

Enfim ... ao falar sobre um aplicativo Web corporativo, as chamadas da interface do usuário para a camada de lógica de negócios devem ser colocadas dentro do controlador (de apresentação).

Isso ocorre porque o controlador realmente lida com as chamadas para um recurso específico, consulta os dados fazendo chamadas para a lógica de negócios e vincula os dados (modelo) à visualização apropriada.

Mud lhe disse que as regras de negócios entram no modelo.
Isso também é verdade, mas ele misturou o modelo (apresentação) (o 'M' no MVC) e o modelo da camada de dados de um design de aplicativo baseado em camadas.
Portanto, é válido colocar as regras de negócios relacionadas ao banco de dados no modelo (camada de dados) do seu aplicativo.
Mas você não deve colocá-los no modelo da camada de apresentação estruturada do MVC, pois isso se aplica apenas a uma interface do usuário específica.

Essa técnica é independente de você usar um design controlado por domínio ou uma abordagem baseada em script de transação.

Deixe-me visualizar isso para você:

Camada de apresentação: Model - View - Controller

Camada de negócios: lógica de domínio - lógica de aplicativo

Camada de dados: Repositórios de dados - Camada de acesso a dados

O modelo que você vê acima significa que você tem um aplicativo que usa MVC, DDD e uma camada de dados independente do banco de dados.
Essa é uma abordagem comum para projetar um aplicativo Web corporativo maior.

Mas você também pode reduzi-lo para usar uma camada de negócios não DDD simples (uma camada de negócios sem lógica de domínio) e uma camada de dados simples que grava diretamente em um banco de dados específico.
Você pode até descartar toda a camada de dados e acessar o banco de dados diretamente da camada de negócios, embora eu não recomende.

Esse é o truque ... Espero que isso ajude ...

[Nota:] Você também deve estar ciente do fato de que atualmente existe mais de um "modelo" em um aplicativo. Geralmente, cada camada de um aplicativo tem seu próprio modelo. O modelo da camada de apresentação é de exibição específica, mas geralmente independente dos controles usados. A camada de negócios também pode ter um modelo, chamado "modelo de domínio". Normalmente, esse é o caso quando você decide adotar uma abordagem orientada a domínio. Esse "modelo de domínio" contém dados e lógica de negócios (a lógica principal do seu programa) e geralmente é independente da camada de apresentação. A camada de apresentação normalmente chama a camada de negócios em um determinado "evento" (botão pressionado etc.) para ler ou gravar dados na camada de dados. A camada de dados também pode ter seu próprio modelo, que normalmente é relacionado ao banco de dados.

A questão é: como isso se encaixa no conceito MVC?

Resposta -> Não!
Bem - meio que faz, mas não completamente.
Isso ocorre porque o MVC é uma abordagem desenvolvida no final dos anos 70 para a linguagem de programação Smalltalk-80. Naquela época, as GUIs e os computadores pessoais eram bastante incomuns e a Internet não era inventada! A maioria das linguagens de programação e IDEs de hoje foram desenvolvidas nos anos 90. Naquela época, os computadores e as interfaces de usuário eram completamente diferentes dos da década de 1970.
Você deve ter isso em mente quando falar sobre MVC.
Martin Fowler escreveu um artigo muito bom sobre MVC, MVP e GUIs de hoje.

O termo lógica de negócios não é, na minha opinião, uma definição precisa. Evans fala em seu livro, Domain Driven Design, sobre dois tipos de lógica de negócios:

• Lógica de domínio.
• Lógica de aplicação.

Esta separação é, na minha opinião, muito mais clara. E com a constatação de que existem diferentes tipos de regras de negócios, também ocorre a constatação de que nem todas elas necessariamente vão para o mesmo lugar.

Lógica de domínio é a lógica que corresponde ao domínio real. Portanto, se você estiver criando um aplicativo de contabilidade, as regras de domínio seriam regras relacionadas a contas, lançamentos, impostos etc. Em uma ferramenta ágil de planejamento de software, as regras seriam como calcular datas de lançamento com base na velocidade e nos pontos da história no backlog, etc.

Para esses dois tipos de aplicativo, a importação / exportação de CSV pode ser relevante, mas as regras de importação / exportação de CSV não têm nada a ver com o domínio real. Esse tipo de lógica é lógica de aplicação.

A lógica do domínio certamente vai para a camada do modelo. O modelo também corresponderia à camada de domínio no DDD.

Entretanto, a lógica do aplicativo não precisa necessariamente ser colocada na camada do modelo. Isso pode ser colocado diretamente nos controladores ou você pode criar uma camada de aplicativo separada que hospeda essas regras. O que é mais lógico nesse caso dependeria da aplicação real.

A1 : A lógica de negócios é Modelparte MVC. A função de Modelé conter dados e lógica de negócios.Controllerpor outro lado, é responsável por receber a entrada do usuário e decidir o que fazer.

A2 : A Business Rulefaz parte Business Logic. Eles têm um has arelacionamento. Business LogictemBusiness Rules .

Dê uma olhada Wikipedia entry for MVC. Vá para Visão geral, onde ele menciona o fluxo deMVC padrão.

Veja também Wikipedia entry for Business Logic. É mencionado que Business Logicé composto por Business Rulese Workflow.

Como algumas respostas apontaram, acredito que haja algum mal-entendido entre arquitetura multicamada e arquitetura MVC.

A arquitetura multicamada envolve dividir seu aplicativo em camadas / camadas (por exemplo, apresentação, lógica comercial, acesso a dados)

MVC é um estilo de arquitetura para a camada de apresentação de um aplicativo. Para aplicativos não triviais, a lógica de negócios / regras de negócios / acesso a dados não deve ser colocada diretamente em Modelos, Vistas ou Controladores. Fazer isso seria colocar a lógica de negócios em sua camada de apresentação e, assim, reduzir a reutilização e a manutenção do seu código.

O modelo é uma escolha muito razoável para colocar a lógica de negócios, mas uma abordagem melhor / mais sustentável é separar sua camada de apresentação da camada de lógica de negócios e criar uma camada de lógica de negócios e simplesmente chamar a camada de lógica de negócios de seus modelos quando necessário. A camada de lógica de negócios, por sua vez, chamará a camada de acesso a dados.

Gostaria de salientar que não é incomum encontrar código que combina lógica de negócios e acesso a dados em um dos componentes do MVC, especialmente se o aplicativo não foi arquitetado usando várias camadas. No entanto, na maioria dos aplicativos corporativos, normalmente você encontra arquiteturas de várias camadas com uma arquitetura MVC na camada de apresentação.

Esta é uma pergunta respondida, mas darei meu "um centavo":

As regras de negócios pertencem ao modelo. O "modelo" sempre consiste em (lógica ou fisicamente separado):

• modelo de apresentação - um conjunto de classes que é adequado para uso na exibição (é adaptado para UI / apresentação específica),
• modelo de domínio - a parte independente da interface do usuário e
• repositório - a parte que reconhece o armazenamento do "modelo".

As regras de negócios vivem no modelo de domínio, são expostas de forma adequada à apresentação ao modelo de "apresentação" e às vezes são duplicadas (ou também aplicadas) na "camada de dados".

Não faz sentido colocar sua camada de negócios no modelo para um projeto MVC.

Digamos que seu chefe decida alterar a camada de apresentação para outra coisa, você seria ferrado! A camada de negócios deve ser uma montagem separada. Um modelo contém os dados provenientes da camada de negócios que passa para a exibição a ser exibida. Em seguida, na postagem, por exemplo, o modelo se liga a uma classe Person que reside na camada de negócios e chama PersonBusiness.SavePerson (p); onde p é a classe Person. Aqui está o que eu faço (a classe BusinessError está ausente, mas também no BusinessLayer):

Q1:

As lógicas de negócios podem ser consideradas em duas categorias:

1. Lógicas de domínio, como controles em um endereço de email (exclusividade, restrições etc.), obtendo o preço de um produto para fatura ou calculando o preço total do shoppingCart com base em seus objetos de produto.

2. Fluxos de trabalho mais amplos e complicados, chamados de processos de negócios, como controlar o processo de registro do aluno (que geralmente inclui várias etapas e precisa de verificações diferentes e possui restrições mais complicadas).

A primeira categoria entra no modelo e a segunda pertence ao controlador . Isso ocorre porque os casos na segunda categoria são lógicas amplas de aplicativos e colocá-los no modelo pode misturar a abstração do modelo (por exemplo, não está claro se precisamos colocar essas decisões em uma classe ou outra de modelo, pois elas estão relacionadas para ambos!).

Veja esta resposta para uma distinção específica entre modelo e controlador, este link para definições muito exatas e também este link para um bom exemplo do Android.

O ponto é que as notas mencionadas por "Mud" e "Frank" acima podem ser verdadeiras, assim como as de "Pete" (a lógica de negócios pode ser colocada no modelo ou controlador, de acordo com o tipo de lógica de negócios).

Por fim, observe que o MVC difere de contexto para contexto. Por exemplo, em aplicativos Android, sugerem-se algumas definições alternativas diferentes das baseadas na Web (veja esta postagem, por exemplo).

Q2:

A lógica de negócios é mais geral e (como "deciclone" mencionado acima), temos a seguinte relação entre eles:

regras de negócios ⊂ lógicas de negócios

Por que você não introduz uma camada de serviço. então seu controlador será mais enxuto e legível; todas as suas funções de controlador serão ações puras. você pode decompor a lógica de negócios conforme necessário na camada de serviço. a reutilização do código é alta. nenhum impacto em modelos e repositórios.

Modelo = código para operações do banco de dados CRUD.

Controller = responde às ações do usuário e passa as solicitações do usuário para recuperação de dados ou exclusão / atualização para o modelo, sujeitas às regras de negócios específicas de uma organização. Essas regras de negócios podem ser implementadas em classes auxiliares ou, se não forem muito complexas, apenas diretamente nas ações do controlador. Finalmente, o controlador solicita que a visualização se atualize para fornecer feedback ao usuário na forma de uma nova tela ou uma mensagem como 'atualizado, obrigado', etc.,

View = UI gerada com base em uma consulta no modelo.

Não há regras rígidas e rápidas sobre aonde as regras de negócios devem ir. Em alguns projetos, eles entram no modelo, enquanto em outros são incluídos no controlador. Mas acho que é melhor mantê-los com o controlador. Deixe o modelo se preocupar apenas com a conectividade do banco de dados.