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

184

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.

— hmthur
fonte

173

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.

— Lama
fonte

5

Obrigado pelo exemplo. Para a entrada de email do administrador (controlando se ela pode ser excluída ou não), não podemos controlar isso usando nosso controlador?

— hmthur

2

@mud e se dividirmos nosso modelo em mais duas camadas, ou seja, camada de serviço e repositório ... a camada de serviço é responsável pela lógica de negócios e o repositório é responsável pela camada de dados ...?

— Dragon

3

@PeterMatisko "Os modelos devem apenas transportar dados." Você não está entendendo o que M significa em "MVC". V é puramente apresentação. C é cola entre apresentação e modelo. (De fato, o "VC" é frequentemente considerado como a camada de apresentação, e as variações populares do MVC, como o MVVM - Model View Viewmodel - tornam isso ainda mais claro.) O M é tudo o resto : todos os dados e lógica da sua aplicação. Você pode segregar dados e lógica de negócios nessa camada e chamar a parte de dados dessa camada de "modelo", mas não é a isso que o "M" em "MVC" se refere.

— Mud

1

@PeterMatisko "em laravel, as pessoas jogam tudo nos controladores ou modelos. Arquitetura ruim e ruim." Mau como ? Seja específico. "V" significa "visualização". Tudo o que não é uma visão necessariamente entra em "M" ou "C". "O MVC simplesmente não é suficiente, ele não fala explicitamente sobre lógica de negócios e onde colocá-lo" Claro que sim. "M" é o modelo do seu aplicativo, que são seus dados, a lógica de negócios em torno dele e qualquer outra coisa que não seja apresentação. "V" e "C" são camadas de apresentação, entrada e saída do usuário.

— Mud

2

@Mud O problema é que o laravel chama um 'Model' apenas um suporte de dados. Quando os tutoriais dizem que o Laravel usa o MVC e, em seguida, você vê que 'Model' tem um objetivo muito específico, acaba sem saber onde colocar a lógica de negócios. E o único lugar razoável é o controlador, o que não é bom. Não estou inventando isso, apenas comentei sobre projetos típicos de laravel (e tutoriais) que eu frequentemente vejo.

— Peter Matisko

191

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.

— Frank
fonte

10

+1 para listar corretamente a diferença entre o aplicativo mvc e o nível n. A maioria dos aplicativos corporativos que desenvolvo possui n camadas e usa o mvc apenas como uma camada de apresentação.

— Retired_User

Vamos dizer 1) Exibir modelos no MVC (camada de apresentação) 2) Algumas tecnologias C # (camada de negócios) para transações autorizadas, lógica de regras de negócios essenciais. 3) Repositório e unidade de trabalho em (Camada de acesso a dados) Por favor, guie algumas tecnologias (ou padrões de práticas recomendadas) que podem ser usadas para criar a Camada de negócios, que deve ter liberdade para permitir e expor o modelo, repositório para acessar do controlador na camada de apresentação (Superior Camada). Basicamente, acredito que adicione, exclua, atualize e sua combinação como lógica de negócios e deve ser mantido em transações. Por favor, espalhe alguma luz adicional sobre isso.

— Mark Macneil Bikeio

Oi Rahul, se eu entendi direito, então você está certo. As operações de CRUD são basicamente partes atômicas das transações comerciais. Pessoalmente, prefiro usar um mapeador OR poderoso como o Hibernate como repositório, em vez de criar o meu. Isso ocorre porque o hibernate já implementa internamente o padrão da unidade de trabalho. Também costumo colocar transações comerciais em serviços comerciais separados.

— 22716 Frank

Para o modelo de visualização, posso dar o seguinte exemplo: Apenas imagine que você possui uma GUI com uma visualização de lista dupla. Essa exibição de lista dupla usa um modelo de exibição de lista dupla como modelo de dados. Esse modelo de dados é apenas uma composição de duas listas simples. Portanto, o modelo de exibição de lista dupla depende da implementação da camada de apresentação, pois não faz parte do modelo de domínio, ao contrário das duas listas simples usadas para criar o modelo de exibição. Dependendo da GUI que você deseja criar, há vários casos em que você pode querer vincular um modelo específico de visualização a uma visualização em vez do modelo de domínio.

— 22416 Frank

A parte das regras de negócios / lógica é um pouco complicada de explicar. Para iniciar qualquer processamento de dados, você chama um método de um de seus serviços. Isso significa que você basicamente inicia uma transação. Se esse método contiver a lógica de negócios, será chamado de "script de transação". Isso geralmente é uma coisa ruim, pois dificilmente é reutilizável. Seria melhor se esse método chamar a lógica comercial do seu modelo de domínio. Isso significa que seu modelo de domínio deve ser desmarcado de forma a poder conter a lógica de negócios. Essa abordagem orientada a domínio não funcionará com um modelo de domínio incompleto ou errado.

— 22716 Frank

73

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.

— Pete
fonte

1

Isso é verdade! Existem dois modelos aqui: seu Modelo de Visualização e Modelo de Domínio. Eu acho que é quase lamentável que o layout dos projetos MVC leve desenvolvedores iniciantes a acreditar que eles deveriam apenas inserir seu código no View Model.

— 31712 Jonathan

1

A sua resposta foi mais aceitável e compreensível. Obrigado.

— revo

27

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.

— deciclone
fonte

16

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.

— treefiddy
fonte

2

Melhor resposta sobre o assunto. Deve ser votado mais alto. A pior resposta é marcada como aceita.

— Peter Matisko

Melhor resposta .. sem dúvida

— salman

Isso depende do tamanho dos dados e do aplicativo? Para um aplicativo pequeno, acho que toda a lógica poderia entrar em modelos sem nenhuma confusão. Em caso afirmativo, qual é o limite de tamanho para começar a separar em uma camada separada?

— mLstudent33

15

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".

— G. Stoynev
fonte

5

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):

— Alex
fonte

Você esclareceria esta afirmação? "Um modelo contém os dados provenientes da camada de negócios que passa para a exibição para exibição."

— Anthony Rutledge

2

Q1:

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

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.
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

— Alisa
fonte

0

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.

— Anil
fonte

-5

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.

— Hoven
fonte

Se você colocar as regras de negócios no controlador e tiver muitas ações, você poderá replicar as regras de negócios muitas e muitas vezes? Não. Você o separará em um método auxiliar ou em uma classe de algum tipo. Coloque essa "coisa" no modelo, onde ela pertence.

— G. Stoynev

3

O MVC não é um padrão de aplicativo para operações do banco de dados CRUD (embora possa ser usado dessa maneira), portanto, o Model não pode ser "código para operações do banco de dados CRUD". O modelo define as entidades do aplicativo, incluindo os dados e as regras de negócios. O controlador coordena a interação entre a vista e o modelo. A visualização é a interface do usuário que expõe o modelo e as operações disponíveis nos modelos expostos pelo controlador.

— Jon Davis