Desafio do Doctrine

Fala teacher, aqui complementando as dúvidas no mesmo desafio.

Outra mudança que precisaria seria trocar o tipo dos telefones na classe Aluno para ArrayCollection. Aplicando isso será possível que funcione o cascade-persist, pois como array puro isso não vai rolar.

Esse ArrayCollection é uma implmentacao do Doctrine. Tudo bem aplicar isso para os outros repositorios com um simples toArray(). Mas a questão é mais filosófica... isso não fere o Clean Code?

Abraço

Carlos Ruesta

Opa, Carlos! Perfeitos os seus questionamentos. Deixa eu tentar responder todos.

Sobre ter o CPF no Telefone, não é necessário. Você vai ter na verdade é uma referência para o Aluno.

Quanto à collection, isso sim seria ferir um pouco o nosso domínio com dependências externas. Nesse casos existem 2 soluções:

1. Aceitar essa dependência tornando seu domínio mais frágil
2. Ter classes específicas do Doctrine na camada de infra que estendam as entidades do domínio

Não existe certo ou errado. Depende de quanta flexibilidade você precisa. Eu provavelmente usaria a primeira abordagem na maioria dos casos.

Bom dia Mestre, obrigado pela resposta.

No final de semana terminei o curso e fiz esse desafio conforme a imagem no link

Adicionei na imagem a forma como resolvi a questão do telefone e o CPF. Precisei adicionar o CPF como atributo do telefone para conseguir fazer o relacionamento. Sem esse atribuito, não funcionaria o persist-cascade.

Acredito que da para fazer sem persist-cascade e implementar o persist do próprio telefone. Mas, mesmo por esse caminho, não enxergo como preencher o campo cpf_aluno (se ele não for um atributo da classe Telefone) sem usar o PDO do doctrine ou puro.

Por favor, teria como ampliar a explicação da sua resposta. Como seria essa referência para o Aluno? Sobre ter o CPF no Telefone, não é necessário. Você vai ter na verdade é uma referência para o Aluno.

Em termos de modelagem do dominio, entendo que o Telefone é um value object que só precisa dos atributos inerentes à ele para se identificar. Mas neste caso é o telefone de um aluno e poderia ser de um professor, funcionario, instituição, etc. Inclusive eu entendo o Telefone como um value object fora do dominio do aluno, mas desde o momento que coloco dentro do dominio do aluno, acredito que deva existir essa relação no modelo para deixar clara essa relação natural do negócio.

Aluno (CPF, Telefones)  ----> Telefone (CPF, TelefoneVO)   ----> TelefoneVO

Em relação à segunda questão dos collections, concordo com você. Inclusive implementei pelo primeiro caminho. Mas como você disse, dependerá da flexibilidade do projeto. Se for um projeto já em andamento com pouco margem para mudança, vai precisar dessa "voltiha".

Muito obrigado,

Carlos Ruesta

Perfeitas, colocações, Carlos! Vamos por partes, então.

A associação one-to-many sempre fica do lado inverso do relacionamento. E não existe no Doctrine uma relação one-to-many com mapeamento apenas em um dos lados, ou seja, ela é sempre bi-direcional.

https://www.doctrine-project.org/projects/doctrine-orm/en/2.8/reference/xml-mapping.html#defining-many-to-one-associations

Sendo muito sincero eu preciso pesquisar mais para saber qual seria a melhor saída para modelar corretamente esse cenário. Talvez alguma outra feature do Doctrine possa até nos ajudar.

Caso você encontre uma saída interessante antes de mim, posta aqui pra eu aprender também. :-D

PS.: Desculpa a demora na resposta. Por algum motivo eu não recebi a notificação dessa mensagem. :'(

Eu estava acompanhando esse tópico de longe por que achei interessante.

Sobre a parte Sobre ter o CPF no Telefone, não é necessário. Você vai ter na verdade é uma referência para o Aluno. Essa forma de modelar não está pensando mais no Doctrine em vez no modelo de domínio? Talvez a razão do problema seja essa.

Sobre No caso seria o CPF quem define esse relacionamento, mas esse atributo não foi incluído na classe de domínio Telefone, somente na tabela de Telefones em banco de dados. Os embeddables do doctrine poderiam contornar esse cenário?