Por que colocar a lógica de negócios no modelo? O que acontece quando tenho vários tipos de armazenamento?

A resposta de ElYusubov geralmente o une, a lógica do domínio deve entrar no modelo e na lógica da aplicação no controlador.

Dois esclarecimentos:

• O termo lógica comercial é bastante inútil aqui, porque é ambíguo. A lógica de negócios é um termo genérico para toda a lógica com a qual os empresários se preocupam, separando-a de meras tecnicalidades, como armazenar coisas em um banco de dados ou como renderizá-las em uma tela. Tanto a lógica de domínio ("um endereço de e-mail válido parece ...") e fluxos de trabalho / processos de negócios ("quando um usuário se inscreve, peça seu endereço de e-mail") são considerados lógica de negócios, sendo que o primeiro pertence claramente ao endereço de e-mail. modelo e o último sendo lógica de aplicação que vai no controlador.
• O MVC é um padrão para colocar coisas em uma tela e permitir que o usuário interaja com ele, não especifica o armazenamento de todo . A maioria dos frameworks MVC são estruturas completas de pilha que vão além do mero MVC e o ajudam a armazenar seus dados, e como os dados que devem ser armazenados geralmente são encontrados no modelo, esses frameworks oferecem maneiras convenientes de armazenar seus modelos. dados em um banco de dados, mas isso não tem nada a ver com o MVC. Idealmente, os modelos devem ser agnósticos quanto à persistência e a mudança para um tipo diferente de armazenamento não deve afetar o código do modelo. Arquiteturas completas têm uma camada de persistência para lidar com isso.

Você e grande parte do mundo da programação parecem entender mal quais são os papéis das partes do MVC. Em suma, eles são:

Modelo = lógica do domínio

Ver = lógica de saída

Controlador = lógica de entrada

Isso significa que o modelo é responsável por toda a lógica de negócios: qualquer coisa que esteja relacionada ao desenho de widgets em uma tela, à condução de uma impressora, à saída de dados como HTML, à análise de solicitações HTTP etc. etc. modelo.

No entanto, muitos dos modernos frameworks "MVC" não fazem MVC, ou rotulam mal suas partes. Muitas vezes, o que é chamado de "modelo" é a camada de persistência do modelo, enquanto a lógica de negócios fica no que eles chamam de "controlador"; o controlador real é geralmente apenas um ponto de entrada central com uma tabela de roteamento e um pouco de código nos "controladores" individuais para despachar a entrada que eles recebem para os processos de negócios corretos. O que esses frameworks chamam de "view" é, na verdade, um pouco de tudo: alguma lógica de apresentação (View), um pouco de manipulação de entrada e validação (Controller), e um pouco mais de lógica de negócios (Model). A maior parte da visão real é geralmente chamada de "modelos".

Você também pode querer ler sobre a Arquitetura Multi-Tier; onde o MVC é de uma forma (o fluxo é Controlador - > Modelo - > Visualização), Multi-Tier é uma coisa bidirecional (Apresentação - > Lógica - > Dados - > Lógica - > Apresentação ), e alguns frameworks que fazem o MVC realmente fazem o Three-Tier, renomeando Presentation to View, Logic para Controller, e Data to Model.

Para realmente isolar a lógica de negócios e separá-la da infraestrutura da camada de apresentação, ela deve ser encapsulada pelos serviços de aplicativo. A arquitetura MVC é uma maneira de implementar a camada de apresentação e deve permanecer nesse escopo, delegando toda a lógica de negócios a esses serviços de aplicativo. Pense nos modelos de visualização como adaptadores entre a visualização e os dados que precisam ser exibidos e / ou lidos. O controlador media a interação entre os modelos de visualização, visualizações e serviços de aplicativos que hospedam a lógica de negócios.

Os serviços de aplicativos implementam casos de uso de negócios e são dissociados da camada de apresentação, seja MVC ou qualquer outra coisa. Por sua vez, os serviços de aplicativos podem hospedar scripts de transação ou um .

Para armazenamento, o serviço de aplicativo pode fazer referência a um repositório ou a qualquer abstração de um mecanismo de persistência. Diferentes implementações podem ser suportadas abstraindo o acesso a dados em uma interface. Normalmente, essas abstrações são leaky e são apenas parcialmente portáveis entre as implementações e muitas vezes é uma tentativa fútil de atingir a portabilidade total .

UPDATE

Minha sugestão é baseada na arquitetura hexagonal . Em uma arquitetura hexagonal, seu modelo de domínio (lógica de negócios) está no centro. Esse núcleo é encapsulado por serviços de aplicativos que funcionam como uma fachada . Os serviços de aplicativos são classes simples que possuem métodos correspondentes aos casos de uso em seu domínio. Para uma discussão aprofundada sobre os serviços de aplicativos, consulte Serviços em Design dirigido por domínio . O exemplo de código contém um PurchaseOrderService , que é um serviço de aplicativo para um domínio de compra. (Observe que um serviço de aplicativo não implica o uso de design orientado a domínio.)

Em uma arquitetura hexagonal, uma camada de apresentação do MVC é um adaptador entre seu modelo de domínio (lógica de negócios) e uma GUI. O modelo de domínio não está ciente da camada de apresentação, mas a camada de apresentação está ciente do modelo de domínio.

Essa solução certamente tem partes móveis do que uma solução que coloca a lógica de negócios no controlador e você deve pesar as desvantagens e os benefícios. A razão pela qual sugiro é porque prefiro manter a lógica de negócios desacoplada da camada de apresentação para combater a complexidade. Isso se torna mais importante à medida que o aplicativo cresce.

Depende do que você entende por lógica comercial. Qualquer "lógica" que dê sentido ao conteúdo do modelo deve estar no modelo. Na questão ligada, a resposta mais votada parece definir "lógica de negócios" como qualquer coisa relacionada a dados; isso faz sentido do ponto de vista de que os dados de uma empresa são seus negócios!

Uma vez eu vi um exemplo do criador do Rails (eu acho) que estava falando exatamente sobre isso - não colocando "lógica de negócios" no modelo. Seu exemplo era uma classe e um método de controlador para registro e login do aplicativo - uma senha fornecida em texto simples era criptografada antes de ser inserida ou consultada no modelo (um banco de dados).

Não consigo pensar em um exemplo melhor de algo que não seja lógica do controlador e que pertença diretamente ao modelo.

O modelo pode ser uma interface para inúmeros armazenamentos de dados, aliviando preocupações de portabilidade. É aqui que se pode encontrar confusão sobre se a interface do modelo é ou não o "controlador".

A seção "Design Patterns" do GoF no MVC, livremente citada:

The MVC triad of classes is used to build user interfaces in Smalltalk-80. The Model is the application object, the View is its screen presentation, and the Controller defines the way the UI reacts to user input. MVC decouples views and models by establishing a subscribe/notify protocol between them. The following diagram shows a model and three views. We've left out the controllers for simplicity.

MVC é tudo sobre UIs. O foco está no modelo e na visualização - definindo e exibindo dados. Observe o "assinar / notificar protocolo" - este é o lugar onde o seu controlador entra. Você pode construir todas as vistas que você quer; contanto que eles adiram ao protocolo, você nunca terá que tocar no modelo ou no controlador.

Se você está falando de desenvolvimento web especificamente, IMHO muitos frameworks web populares são rápidos e frouxos com o termo MVC e suas definições de componentes.