1
resposta

Organização do script de atualização dessa atividade em um projeto real

Em um projeto real no padrão MVC(usando só Services como camada a mais) em qual camada deveria ficar esse script de atualização? E ele deveria ser dinâmico né? Então como seria?

Eu tenho dificuldade de saber quando usar o MVC padrão, quando usar MVC + Service ou MVC + Service + Repository e deve ter outras variações que não sei.

link: https://cursos.alura.com.br/course/websockets-comunicacoes-tempo-real-socket-io-mongodb/task/117126?b2cUser=true

obs: Eu não sei se pode passar o link assim como passei por causa do "User" contido nele. Pode?

1 resposta

Ola!

Em um projeto real usando MVC com uma camada de Services, esse script de atualização com updateOne não deveria ficar solto nem no Controller. O lugar mais adequado é o Service, porque é ali que vivem as regras de negócio. O Controller apenas recebe a requisição (HTTP ou Socket), extrai os dados necessários e delega a responsabilidade para o Service. Já o Model fica restrito a representar o schema e executar as operações no banco.

No curso, o update aparece de forma bem direta porque o foco é ensinar o método do MongoDB. Em produção, esse update quase nunca é “fixo”. Ele costuma ser dinâmico, montado a partir dos dados recebidos e das regras da aplicação. O Service é quem decide o que pode ou não ser atualizado, em que momento isso acontece e quais campos realmente devem ir para o updateOne. Assim você evita regras espalhadas e Controllers cheios de lógica.

Sobre a dúvida maior de arquitetura, dá para pensar assim: MVC puro funciona bem para projetos pequenos, com poucas regras e CRUD simples, mas costuma gerar Controllers grandes conforme a aplicação cresce. O MVC + Service já resolve isso muito bem e acaba sendo o padrão mais comum no mundo real, principalmente em Node.js. Ele organiza melhor o código, facilita testes e evita repetição de lógica. Já adicionar uma camada de Repository só faz sentido quando o projeto é grande o suficiente para justificar esse nível extra de abstração, como quando você precisa trocar o banco de dados com facilidade ou isolar completamente o acesso aos dados para testes. Caso contrário, é mais complexidade do que benefício.

E sobre o link da Alura, pode ficar tranquilo. Esse tipo de URL com parâmetro de usuário é comum no fórum e não expõe informação sensível, então não tem problema compartilhar. :)