Olá, para a ideia de organizar o código e colocar o insert de telefone em outra classe na pratica ele seria uma DAO ou Repository? seria uma boa pratica deixar o modificador de acesso dessa nova classe apenas com visibilidade dentro do pacote?
Olá, para a ideia de organizar o código e colocar o insert de telefone em outra classe na pratica ele seria uma DAO ou Repository? seria uma boa pratica deixar o modificador de acesso dessa nova classe apenas com visibilidade dentro do pacote?
hoje, com a Alura e o Google Gemini
Olá, acredito que esse assunto seja mais profundo do que uma simples dedução de "se seria DAO ou Repository ou como determinar o acesso a classe". Tentarei aqui esclarecer alguns conceitos e trazer alguns questionamentos à tona, e darei a minha opinião quanto a sua pergunta.
Primeiramente, o assunto é mais profundo do que a pergunta porque ele acaba por ser sensível ao seu domínio de negócio, e poder ser discutido tanto no âmbito do modelo de domínio quanto no âmbito da persistência de dados. Aqui focaremos no âmbito do modelo de domínio.
No âmbito do seu modelo de domínio, a forma com que o telefone é tratado, do ponto de vista do negócio, pode determinar como que será feita essa modelagem. No caso de exemplo do curso, o telefone é tratado como um objeto de valor da entidade Aluno (mas em um outro domínio de negócio, por ex.: telecomunicação, poderia ser uma entidade), dessa forma, o telefone não possui, do ponto de vista da modelagem de domínio, uma identidade. Logo, ele é uma classe com o ciclo de vida dependente do ciclo de vida da entidade de Aluno (diz-se que o telefone compõe o aluno).
Existe muito material na internet que faz a comparação entre DAO e Repositórios [1] e deixa claro as suas diferenças. A grande questão é que o Repositório é um conceito que faz parte do modelo de domínio, que acaba por cuidar do ciclo de vida dos agregados, e vai compor a linguagem onipresente do projeto. Visto isso, não é apropriado a criação de um repositório especificamente para o telefone, já que o telefone em si, separado da entidade Aluno (do agregado), não possui um ciclo de vida.
A manipulação dos telefones através de um DAO pode** (olhar nota abaixo), também, não ser apropriado, já que você irá manipular individualmente um elemento que faz parte de um agregado. Um agregado é um grupo coeso de objetos do domínio que devem ser tratados como uma unidade, ou seja, enxerga-se o agregado como uma unidade.
Toda a comunicação com o agregado vai acontecer através da sua raiz de agregado (no caso do curso, o próprio aluno) e o agregado possuirá um conjunto de invariantes que devem ser respeitadas sempre ao final de qualquer transação no agregado [2]. Ou seja, o agregado definirá uma fronteira transacional que são impostas pelas invariantes. A partir do momento que eu altero externamente (ou seja, usando um DAO, diretamente no banco de dados, ou por qualquer outro meio que não seja pela minha raiz do agregado), eu estou violando a minha fronteira transacional e contornando as invariantes impostas pelo agregado, podendo gerar instâncias de agregados inconsistentes.
Então, resumindo tudo isso, na minha opinião, não vejo como apropriado você definir essa sua classe para manipular os telefones como um repositório, como comentado no terceiro parágrafo. Também, não vejo como ideal a criação de um DAO para o acesso e manipulação direto das informações de telefone. Talvez você tenha uma boa razão para isso, e não sou eu que vou impedi-lo. A minha ideia aqui é deixar claro as possíveis consequências disso. Quanto a visibilidade do DAO, na minha opinião, ele deve ser o mais restrito possível.
Notas:
** Não estou afirmando que será inapropriado para todas as situações, mas caso seja feito, é importante saber as razões e as consequências de se fazer isso.
Referências: