Como um modelo deve ser estruturado no MVC?

No MVC, o modelo representa a lógica de negócios e os dados do aplicativo. Ele encapsula lógica e regras específicas do domínio, permitindo que o aplicativo execute tarefas e tome decisões sem depender da interface do usuário ou do controlador.

Conceito de modelo:

• Um modelo não é uma classe ou objeto. É uma camada composta por três elementos principais:

  • Objetos de domínio: representam entidades de negócios e contêm lógica específica para o domínio do problema.
  • Mapeadores de dados: tratam da persistência de dados e da interação com armazenamento externo , como bancos de dados.
  • Serviços: orquestrar interações entre objetos de domínio e mapeadores de dados, fornecendo uma interface de nível superior para interagir com o negócio lógica.

Separação de preocupações:

• A camada do modelo é separada da camada da UI (visualização e controlador) .
• A comunicação com o modelo ocorre exclusivamente por meio de serviços, garantindo uma separação clara de preocupações e evitando o vazamento da lógica do domínio na interface do usuário ou no código do controlador.
• Essa separação promove o Single Princípio de Responsabilidade (SRP), flexibilidade e testabilidade mais fácil.

Acessando o modelo:

• Em visualizações e controladores, você pode acessar serviços de modelo por meio de injeção de dependência usando estruturas como o contêiner DI do Symfony ou Auryn.
• Os serviços podem ser injetados em construtores ou acessados ​​​​por meio de um fábrica.
• Essa abordagem garante que todos os serviços necessários estejam disponíveis para esses componentes.

Modificando o estado do modelo:

• Controladores são responsáveis ​​por lidar com a entrada do usuário e modificar o estado do modelo.
• Eles chamam métodos de serviço, que por sua vez interagem com objetos de domínio e mapeadores de dados para executar a lógica necessária operações.

Persistência de dados:

• Os objetos de domínio representam entidades comerciais, mas não têm conhecimento do armazenamento.
• Identificadores de dados persistência e recuperação de dados de armazenamento externo.
• Essa separação permite que a lógica de negócios permaneça independente da tecnologia de armazenamento específica usado.

Benefícios da separação:

• Aplica o SRP atribuindo responsabilidades claras a cada camada.
• Melhora a legibilidade do código e testabilidade isolando a lógica de negócios.
• Oferece flexibilidade na modificação da lógica de negócios ou armazenamento de dados sem afetar outros componentes.
• Simplifica o desenvolvimento de APIs externas, fornecendo uma interface consistente para acessar serviços de modelo.

Comentários adicionais:

• As tabelas de banco de dados nem sempre são mapeadas diretamente para objetos de domínio e mapeadores de dados.
• As visualizações não são modelos, mas lidam com lógica e modelo de apresentação seleção.
• Deve haver uma relação 1:1 entre visualizações e controladores para cada página ou tela.