Em um sistema de software estruturado em MVC (Model/View/Co...

A alternativa correta é a C.

Vamos entender o porquê e esclarecer as demais alternativas.

Alternativa C: O “model”, ou modelo, é o responsável por armazenar e oferecer de forma coerente os dados referentes a uma entidade modelada no sistema. É nesta entidade que ficam as regras de negócio da aplicação.

Essa alternativa está correta porque, no padrão MVC (Model-View-Controller), o Model realmente representa a lógica de negócios ou as regras de negócio da aplicação. Ele é responsável por gerenciar os dados da aplicação, responder às instruções do controlador e atualizar a visão quando os dados mudam.

Alternativa A: Está incorreta porque ela descreve uma função que é atribuída ao Controller, e não ao Model. O Controller é que recebe e processa as requisições feitas pelo usuário através da View e, em seguida, interage com o Model para obter ou modificar os dados.

Alternativa B: Está incorreta ao afirmar que o Model deve ser o mais simples possível, o chamado "thin model". Na verdade, o Model pode ser bastante complexo, pois ele deve incluir todas as regras de negócio e lógica de dados da aplicação. Um thin model poderia ser uma abordagem inadequada dependendo da complexidade da aplicação.

Alternativa D: Está incorreta porque coloca no Controller a responsabilidade de armazenar as regras do negócio. No padrão MVC, as regras de negócio devem estar no Model. O Controller deve mediar a interação entre o View e o Model, mas não conter a lógica de negócios.

Alternativa E: Está incorreta porque a função descrita é do Model, não da View. A View é responsável pela apresentação dos dados, ou seja, ela exibe os dados ao usuário e pode permitir a interação com esses dados, mas não deve armazenar dados nem conter a lógica de negócios.

Compreender a arquitetura MVC é crucial para desenvolver sistemas de software de maneira organizada e eficiente. O Model gerencia os dados e regras de negócio, o View é responsável pela interface de usuário e apresentação dos dados, e o Controller atua como intermediário entre o Model e o View, controlando o fluxo de dados e a lógica de aplicação.

Controverso hein...

A alternativa E) está errada pois quem armazena e oferece os dados são a Model e a Controller. O que a View faz é mostrar os dados ao usuário.

Modelo (Model): responsável por modelar os dados e o comportamento por trás das regras de negócio. Se preocupa com o armazenamento, manipulação e geração de dados.

Alternativa C

É na entidade que ficam as regras de negócio da aplicação? Questão passível de anulação.

Essa foi a questão mais precisa de MVC que ja vi até agora, maravilha de questão! Galera pode estar estranhando o gabarito porque aparentemente as bancas adotam um entendimento geral de MVC que vem do CESPE, com "seu jeitinho" ou por conhecimento empírico do dia a dia.

Sim, o Model muitas vezes são "meros" objetos ou estruturas que modelam as entidades do banco de dados e suas restrições, com seus métodos de persistência. Isso é a "lógica de negócios" de que trata a teoria do MVC em 1979, não se refere a comportamentos da aplicação (que muitas vezes também são chamadas de regras de produtos/negócio no dia a dia do programador).

Isso induzia a codificação de controllers grandes e complexos, já que implementam todo o comportamento da aplicação(ou fluxo da aplicação) e por isso, com o advento das práticas de Clean Code (2008), foi introduzido a ideia de "services", que "quebram" esse controller em serviços específicos para respeitar o princípio da responsabilidade única.

Os métodos ágeis vieram, as regras de negócio são cada vez mais dinâmicas e isso fez com que adotássemos cada vez mais camadas no desenvolvimento além das 3 previstas inicialmente no MVC (arquitetura SOA, as APIs, os Web Services, etc), até chegar nos microsserviços.

Portanto, o entendimento de "regras/lógica de negócio" de 1979 era muito restrito a banco de dados (diagramas de classes etc), o restante era tratado como comportamento da aplicação e requisitos (diagramas de atividade, casos de uso, sequência, etc). Essa distinção teórica a respeito de lógica de negócio e comportamento existe até hoje, exceto no dia a dia do programador, o que pode confundir nas questões de concursos.