Onde estão as regras de negócios no MVC

Question

Agora que todo mundo está falando sobre MVC, percebo que as regras de negócio não estão sendo abordadas.Nos velhos tempos da arquitetura de 3 camadas, as regras de negócios estavam na camada intermediária.Onde eles se enquadram no novo MVC?

Answer 1

No início, eu diria que eles pertencem ao modelo. o Entrada do MVC na Wikipedia Parece concordar: "No MVC, o modelo representa as informações (os dados) do aplicativo e as regras de negócios usadas para manipular os dados". Afinal, pelas 'regras de negócios', queremos dizer os algoritmos funcionais e a lógica que codificam o domínio com o qual seu aplicativo está envolvido, em oposição à lógica relacionada a entrada/saída. Essa lógica principal relacionada aos negócios não- ou não deve mudar com base no que está sendo exibido ao usuário (que é o domínio da exibição) ou a entrada do usuário (que é recebida principalmente pelo controlador).

Na minha experiência, fazer esse tipo de pergunta foi muito revelador durante o processo de desenvolvimento de software: encontramos um grande número de coisas que eram consideradas 'regras de negócios' por algumas pessoas, mas acabamos sendo outra coisa. Se não for uma regra de negócios verdadeira, pode não pertencer ao modelo.

Answer 2

A razão pela qual você nunca vê o endereço do MVC "Regras de Negócios" é que o MVC em geral é um padrão de apresentação. Está focado em como estruturar seu aplicativo. O modelo, por exemplo, pode ser considerado um modelo de apresentação. O modelo do seu aplicativo, que a visualização renderiza.

No entanto, para criar o modelo de apresentação, você geralmente precisa ir aos seus modelos de domínio onde toda a sua lógica de negócios vive. Nesse ponto, o MVC não dita onde esse código vive fisicamente. Está em outro nível? MVC não se importa.

Answer 3

As regras de negócios sempre vivem no modelo. O modelo é a parte que você pode ressuscitar com uma interface do usuário completamente diferente. Obviamente, a visualização depende completamente das opções da interface do usuário e o controlador deve retirar os dados do modelo e informar a visualização para renderizá -lo.

Colocar a lógica de negócios na vista é ruim porque vincula a estrutura à apresentação.

Colocar a lógica de negócios no controlador é ruim porque divide seu domínio de negócios entre os dados persistidos pelo modelo e pelas regras no controlador.

Answer 4

Uma citação de uma Wikipedia Artigo:

O MVC é frequentemente visto nos aplicativos da Web, onde a visualização é a página HTML real, e o controlador é o código que reúne dados dinâmicos e gera o conteúdo no HTML. finalmente, o modelo é representado pelo conteúdo real, geralmente armazenado em um banco de dados ou em nós XML, e as regras de negócios que transformam esse conteúdo com base em ações do usuário.

Answer 5

Existe alguma razão pela qual você não pode misturar MVC e Ntier?Nosso aplicativo faz exatamente isso.Nossos controladores são usados ​​para validação de dados e decidem quais chamadas da camada de negócios devem ser feitas.

OurApp.Web - Projeto Asp.net MVC
OurApp.Business - Biblioteca de camadas de negócios
OurApp.DataAccess - Biblioteca de camada de dados
OurApp.Entities – Basicamente todos os ‘modelos’ compartilhados por todas as camadas

Answer 6

As regras de negócios devem estar no modelo, não no controlador. O controlador e a visualização fazem parte da camada de apresentação.

O modelo representa as entidades e funcionalidade do domínio.

O controlador é apenas um gerente para obter entrada e solicitações do usuário, executando ações no/no modelo e mapeando isso para as visualizações na camada de apresentação. O controlador também não é apenas um mediador, a visualização ou o controlador podem atuar no modelo.

Answer 7

Esta é uma pergunta publicada antigamente, mas eu gosto que um repositório de regras seja completamente independente de qualquer parte de um aplicativo. Vários aplicativos, várias implementações de uma camada comercial, devem poder acessar uma renderização estática de um repositório de regras de negócios. Decisões de separação simples como essa fazem uma migração da Web de desktop ->, por exemplo, trivial.

Na minha arquitetura, View -> Model -> Controller -> Nível de negócios -> Regras Repositório, ou seja, o controlador acessa dados grosseiros, conforme apresentado pela camada/camada comercial, alimenta -o com o modelo que o massageia em uma forma apresentável e a forma e a forma e a forma e a forma apresentável e a forma apresentável e a forma e a forma de massageia em uma forma apresentável, e a forma e a forma e a forma apresentável e a forma e a forma apresentável e a forma e a forma e a forma apresentável, e a forma e a forma e a forma apresentável e a forma e a forma apresentável e a forma apresentável e a forma apresentável e a forma apresentável e a forma e a forma e a forma apresentável, e a forma e a forma apresentável e a forma e a forma apresentável e a forma apresentável e a forma apresentável e a forma apresentável e a forma e a forma de massageia em uma forma e Ver passivamente o exibe. O nível comercial, que é reutilizável em qualquer formato de apresentação, terá regras explícitas e acesso a um subsistema com regras implícitas. Por design, cada componente ignora os detalhes de um componente acima dele.

Answer 8

Eu acho que a questão é uma questão de definição. Parece -me que a lógica para apresentar as telas na ordem necessária é um problema do controlador e eu vi alguns projetos que usam um mecanismo de regras para determinar o pedido e o que é necessário a entrada do usuário. Isso não é o mesmo que as regras de negócios IMHO.

Answer 9

Vocês estão errados, as regras de negócios vivem dentro do controlador e não no modelo ...