Ainda sobre conceitos MVC

Opa, Flávio. Gostei da sua dúvida. Vamos por partes.

View chama a rota

Acho que eu entendi o que você quis dizer, mas conceitualmente essa afirmação é errada. Uma requisição é feita para o front-controller (nosso index.php). O front-controller que define qual controller vai ser chamado.

O model consulta o banco[...]

A camada de modelo é composta por repositórios, entidades, services, etc. Quem vai no banco, normalmente é um repositório. Uma classe específica de acesso a dados. E ela busca do banco entidades. Então, utilizar o nome específico de cada conceito ao invés de só "model" é bem importante pro entendimento de toda a arquitetura.

o que não for exibição nem consulta ao banco, é tarefa do controller.

Não. O controller tem a seguinte responsabilidade: Receber uma requisição (se for web, HTTP) e devolver uma resposta (utilizando o mesmo protocolo da requisição). A responsabilidade do Controller deve parar aí.

Regras de negócio devem estar em suas classes de domínio. Sua classe Pagamento deve ser a responsável por determinar se as parcelas estão corretas. Sua classe Item deve verificar se seu valor é válido, e um conjunto de itens (que pode ser um CarrinhoDeCompras) deve calcular o valor total baseado nos valores de cada Item. Quando nossas regras de negócio não "cabem" em uma entidade, devemos criar uma classe específica para ela. Essas classes de ação são chamadas de Services.

Um estudo mais aprofundado sobre isso é super recomendado, então livros sobre arquitetura, DDD, etc são o caminho pra você entender com mais clareza, mas espero ter dado uma pequena luz pra sua dúvida. :-D

Acho que entendi um pouco melhor agora. Juntando com o outro post que vc me respondeu, ficou mais claro.

É impressão minha ou parece que a parte de Model é a mais complexa?

Ainda tenho algumas dúvidas, como por exemplo o que vc disse sobre as regras de negócio que devem estar em suas classes de domínio. Poderia me explicar melhor isso?

Vc deu exemplos de que as classes têm responsabilidades, como as classes Pagamento, Item e CarrinhoDeCompras. Elas fazem parte do Model, certo? Estas que são as classes chamadas de Services?

Podemos afirmar que Repositórios, Entidades e Services são classes (arquivos de php), todas elas pertencentes ao model. É certo afirmar isso?

Baseado nisso, temos:

• Repository: É o que vai lá no banco e faz o CRUD.
• Services: São as que fazem as operações (cálculos, verificações, validações, etc.).
• Entidade: São classes que possuem os atributos, métodos acessores, etc, que são usadas pelos Repositorios para trazer os dados (de usuários, pagamentos, alunos, etc.).

Esses três são isso mesmo?

Outra coisa. Quando vc diz: Quando nossas regras de negócio não "cabem" em uma entidade..., vc poderia dar um exemplo de quando elas cabem dentro de uma entidade? Para eu poder fazer um paralelo mental aqui.

Seria muito legal ver tudo isso com PDO. Vimos com Doctrine, mas é muita informação para assimilar de uma vez só.

No treinamento novo de PDO que irá sair, veremos isso tudo?

Obrigado!

Bora por partes de novo, Flavio. :-D

É impressão minha ou parece que a parte de Model é a mais complexa?

Exatamente. Dentro da camada de Model existe um mundo pra gente estudar ainda.

Ainda tenho algumas dúvidas, como por exemplo o que vc disse sobre as regras de negócio que devem estar em suas classes de domínio. Poderia me explicar melhor isso?

Uma classe de domínio é uma classe que represente algo real do domínio do seu negócio. Em uma escola, a classe Aluno seria uma classe de domínio. Nela, você teria os atributos referentes a um aluno, além das regras de negócio que envolvam um aluno (matricular, trancar, aprovar, reprovar, etc)

Vc deu exemplos de que as classes têm responsabilidades, como as classes Pagamento, Item e CarrinhoDeCompras. Elas fazem parte do Model, certo? Estas que são as classes chamadas de Services?

Não essas são entidades. Services são classes que criamos especificamente para uma ação apenas.

Podemos afirmar que Repositórios, Entidades e Services são classes (arquivos de php), todas elas pertencentes ao model. É certo afirmar isso?

Correto

Repository: É o que vai lá no banco e faz o CRUD. Services: São as que fazem as operações (cálculos, verificações, validações, etc.). Entidade: São classes que possuem os atributos, métodos acessores, etc, que são usadas pelos Repositorios para trazer os dados (de usuários, pagamentos, alunos, etc.).

Mais ou menos. Você está pensando de forma procedural, e não de forma orientada a objetos. Um repositório não necessariamente faz todo o CRUD, se não for preciso. Um repositório fornece o acesso aos dados, como se fosse uma coleção. Ex.:

RepositorioDeAlunos pode ter o método alunosMatriculados, entende?

Quanto às entidades, não, elas não tem só atributos e métodos acessores. Isso é o que é conhecido como modelo anêmico. Entidades são o principal ponto do seu domínio e devem conter sua regra de negócio.

Outra coisa. Quando vc diz: Quando nossas regras de negócio não "cabem" em uma entidade..., vc poderia dar um exemplo de quando elas cabem dentro de uma entidade? Para eu poder fazer um paralelo mental aqui.

Exemplo: Você precisa criar um usuário. Pra isso, ele precisa de uma senha. É responsabilidade do usuário criptografar a própria senha? Não, né!? Isso não é responsabilidade de nenhuma classe de domínio. Então você precisa de uma classe específica para criptografar senhas. Essa classe é o que chamamos de Domain Service.

Ainda há Application Service e Infrastructure Service, mas aí já entra em conceitos mais avançados...

No treinamento novo de PDO que irá sair, veremos isso tudo?

Tudo não, Flavio Veremos a parte de repositório e entidade, apenas. Eu estou planejando um curso de arquitetura que possivelmente trate um pouco desses assuntos, mas não posso prometer nada ainda. rsrsrs

Até lá, super recomendo que você estude sobre DDD e Clean Architecture.

Tá certo. Vou refletir aqui sobre as respostas e estudar a recomendação.

Estou aguardando ansioso pelo novo curso.

Obrigado!