Solucionado
Não fica muito claro mas deduz-se q a busca das personalidades se deu com sucesso porque o nome da struct e a tabela são parecidos ? É algum tipo de convenção ? Pq não faz sentido nenhum a aula não ter relatado isso. Já que se dá um Find sem referenciar nenhuma tabela.
Olá, Alex! Tudo bem?
Isso realmente pode parecer um pouco mágico à primeira vista, mas vou te explicar como isso funciona!
No GORM, a convenção é que o nome da tabela é o plural do nome da struct em minúsculas, a menos que você especifique de outra forma. No seu caso, a struct Personalidade está provavelmente associada a uma tabela chamada personalidades. Isso é feito automaticamente pelo GORM, que é bastante opinativo em relação a convenções como essa.
Quando você executa database.DB.Find(&p), o GORM entende que deve buscar na tabela associada ao tipo de p, que é um slice de Personalidade. Portanto, ele busca na tabela personalidades sem que você precise especificar explicitamente.
Se você quiser que uma struct se relacione com uma tabela que não segue essa convenção de nomenclatura, você pode usar a função TableName() para especificar o nome da tabela desejado. Por exemplo:
type Personalidade struct {
gorm.Model
Nome string
}
func (Personalidade) TableName() string {
return "nome_da_tabela_customizada"
}
Isso direcionaria o GORM para usar "nome_da_tabela_customizada" em vez do nome padrão baseado na struct.
Espero que essa explicação tenha esclarecido suas dúvidas.
Bons estudos!
Uma dúvida, sobre a arquitetura dos sistemas em Go, achei meio bagunçado o controllers e os routers, existe alguma outra forma de organizar melhor? Penso que a medida que o sistema cresce por virar uma bagunça muito grande.
Bom dia, Pablo!
Entendo a sua preocupação na questão de escalabilidade do projeto, então vamos conversar um pouco sobre a arquitetura dele.
A arquitetura utilizada no projeto da aula é o MVC (Model, View e Controller) ela é bem comum e grande parte dos projetos a utilizam, pois é uma estrutura de fácil entendimento.
Para a melhoria dela, pensando na escalabilidade, são adicionadas outras camadas de abstração, como o services que, geralmente, estabelece classes modelos para requisições HTTP que acontecem na camada do Controller, visando a não replicação de código.
Mas definitivamente o modelo MVC pode ser estranho de início, quando não entendemos o que acontece em cada camada.
Na imagem acima vemos todo o processo que ocorre quando o usuário faz uma requisição para uma API no modelo MVC. Onde, no primeiro momento, a camada de Controller recebe a requisição e realiza outra para a camada de Model, buscando a tabela e os dados requiridos na busca do usuário. Após a camada Model receber essa requisição, ela retorna uma resposta contendo as informações pedidas pelo Controller e o mesmo envia essas informações, agora tratadas ou ajustadas ao pedido do usuário para a camada View que mostrará as informações para o usuário.
No caso do projeto, a última etapa não é bem aplicada em API's, já que a forma de visualização é feita via terminal ou aplicações como Postman ou Insomnia.
Enfim, toda essa informação é importante para te dizer que a arquitetura utilizada tem sua complexidade e simplicidade andando juntas e podendo ser ajustadas.
Caso tenha ficado com alguma dúvida estarei à disposição para ajudar.