3
respostas

Por que não temos rota de matriculas?

A professora decidiu, em vez de criar um arquivo de rota para matrículas, chamar o controller de matrícula no arquivo de rota de pessoa. Mas por quê? Isso não viola a regra de responsabilidade única do SOLID? Não seria melhor ter um arquivo de rota para matrículas?

"pessoasRoute.js":

const { Router } = require('express');
const PessoaController = require('../controllers/PessoaController.js');
const MatriculaController = require('../controllers/MatriculaController.js');

const pessoaController = new PessoaController();
const matriculaController = new MatriculaController();

const router = Router();

router.get('/pessoas', (req, res) => pessoaController.pegaTodos(req, res));
router.get('/pessoas/todos', (req, res) => pessoaController.pegaTodasAsPessoas(req, res));
router.get('/pessoas/:id', (req, res) => pessoaController.pegaUmPorId(req, res));
router.post('/pessoas', (req, res) => pessoaController.criaNovo(req, res));
router.put('/pessoas/:id', (req, res) => pessoaController.atualiza(req, res));
router.put('/pessoas/:estudante_id/cancela', (req, res) => pessoaController.cancelaRegistroEstudante(req, res));
router.delete('/pessoas/:id', (req, res) => pessoaController.exclui(req, res));
router.get('/pessoas/:estudante_id/matriculas', (req, res) => pessoaController.pegaMatriculasAtivas(req, res));
router.get('/pessoas/:estudante_id/matriculas/todos', (req, res) => pessoaController.pegaTodasAsMatriculas(req, res));
router.get('/pessoas/:estudante_id/matriculas/confirmadas', (req, res) => matriculaController.pegaMatriculasPorEstudante(req, res));
router.get('/pessoas/matriculas/lotadas', (req, res) => matriculaController.pegaCursosLotados(req, res));
router.get('/pessoas/:estudante_id/matriculas/:id', (req, res) => matriculaController.pegaUm(req, res));
router.post('/pessoas/:estudante_id/matriculas', (req, res) => matriculaController.criaNovo(req, res));
router.delete('/pessoas/:estudante_id/matriculas/:id', (req, res) => matriculaController.exclui(req, res));

module.exports = router;
3 respostas

Ola!

Nessa parte, a professora optou por não criar um arquivo separado de rota para matrículas porque as matrículas são um recurso dependente de pessoas. Em outras palavras:

Uma matrícula só existe vinculada a uma pessoa (estudante).

Vamos entender por partes:

  • Relação entre Pessoa e Matrícula

No modelo do projeto, temos algo assim:

  • Pessoa → representa um estudante.
  • Matrícula → pertence a uma pessoa específica (chave estrangeira estudante_id).

Logo, o caminho natural das rotas segue essa hierarquia:

/pessoas/:estudante_id/matriculas

Isso deixa claro que estamos manipulando matrículas de uma pessoa específica, e não um recurso independente como:

/matriculas
  • Organização das rotas

Por esse motivo, a professora decidiu manter as rotas de matrículas dentro do arquivo pessoasRoute.js, já que elas fazem parte da “sub-relação” de pessoas.
Essa abordagem não quebra o SRP, porque:

  • As regras de negócio de matrícula ainda estão no MatriculaController, separado do PessoaController.
  • O arquivo de rotas (pessoasRoute.js) apenas organiza endpoints — ele não contém lógica de negócio.

Portanto, a separação de responsabilidades ainda existe:

  • Controllers → lógica da aplicação.
  • Routes → definição dos caminhos e mapeamento para os controllers.
  • Quando faria sentido criar uma rota própria de matrículas

Seria interessante ter um matriculasRoute.js se as matrículas pudessem ser manipuladas independentemente das pessoas.
Por exemplo:

/matriculas
/matriculas/:id

Mas, como o modelo do sistema atual pressupõe que toda matrícula pertence a uma pessoa específica, isso não seria coerente neste contexto.

Olá, Luidi! Como vai?

Complementando o que o colega disse, a decisão de não criar um arquivo de rota separado para matrículas e, em vez disso, integrá-las nas rotas de pessoas pode ter sido feita por algumas razões práticas:

  1. Relacionamento entre Entidades: No contexto de um sistema de gerenciamento escolar, matrículas são fortemente relacionadas a pessoas (estudantes). Portanto, faz sentido agrupar as rotas de matrículas sob as rotas de pessoas, já que as matrículas dependem diretamente de um estudante.

  2. Facilidade de Navegação: Ao agrupar as rotas de matrículas com as de pessoas, você pode simplificar a estrutura de navegação do seu API. Isso pode facilitar a compreensão de como as matrículas estão associadas aos estudantes.

  3. Escopo do Projeto: Dependendo do tamanho e complexidade do projeto, pode ser mais prático manter as rotas juntas para evitar a criação de muitos arquivos de rota, o que poderia tornar o projeto mais difícil de gerenciar.

  4. Decisão de Design: Às vezes, decisões de design são tomadas para simplificar o código ou por preferência pessoal do desenvolvedor ou da equipe.

No entanto, você está certo ao pensar sobre a responsabilidade única. Se o projeto crescer ou se as rotas de matrícula se tornarem mais complexas, pode ser uma boa ideia separá-las em um arquivo próprio para manter a clareza e a manutenibilidade do código.

Espero ter ajudado e bons estudos!

Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.

Tu concorda com o colega que não quebra a regra de responsabilidade única? Ou quebra mas tudo bem, pq não precisamos seguir todas as regras necessariamente? E se o projeto crescer q nem tu disse, poderíamos criar um arquivo de rotas para matrículas, mas poderia deixar também as rotas de matrículas ligadas à rota de estudante ou teria que remove-las?