Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Dúvida sobre a camada Controller

Olá pessoal, primeiramente estou gostando muito do curso, pois ele apresenta os componentes essenciais de todo projeto com POO e MVC.

Tenho uma dúvida em relação ao controller, eu percebi que ele é uma das camadas cujas classes, mais podem crescer e são passíveis de alteração. Quando elas começam a crescer muito e em sistemas mais complexos elas vão com certeza, o que posso fazer pra refatorar? Existe algum pattern ou técnica? Eu poderia criar vários métodos private dentro do controller pra organizar melhor? Pesquisando alguns sistemas do github eu percebo que muitos controllers crescem muito, tipo até muitos mais do que 1000 linhas e ficam completamente confusos cheio de IFs, indo contra ao objetivo do MVC.

Desde já muito obrigada!

4 respostas

Olá Laís

Aqui vai algumas dicas:

  • Procure manter os teus controllers o mais simples possível. Eles devem fazer uma coisa apenas que é buscar dados e mandar os dados pra view.

  • Quando falo em buscar dados, o ideal é manter a lógica toda que a busca fora do controller, num service por exemplo, ou repositório, e no teu controller chamar apenas o método que retorna os dados necessários e mandar pra view.

  • Cada controller deve ser responsável por responder por uma única rota ou recurso. Ou seja, o controller der Usuarios não pode ser o mesmo a lidar com as rotas dos Cursos.

Penso que estes trÊs podem já ajudam a manter um controllher mais clean

Abraços

WeezHard Muito obrigada pela resposta!

Sua resposta foi muito informativa e útil porém sempre surgem novas perguntas.

Em relação ao primeiro ponto, eu percebo que os controllers pelo menos dos exemplos que eu vi, acabam fazendo mais do que isso, por exemplo se vc recebe um array dentro de de um POST, é um conjunto de dados que devem ser tratados e manuseados, ai você é obrigado a utilizar um for e um tratamento pra validar os dados, dependendo do número de dados que vc receber você precisa inserir estruturas condicionais pra tratar cada dado da maneira correta, tem como organizar melhor isso?

No segundo ponto você quis dizer a camada model certo? e service vc diz os frameworks como o doctrine?

No terceiro ponto me surgiu uma dúvida, o vinicius criou diversos controllers pra lidar com uma entidade apenas que é o "curso", um controller pra deletar, outro pra inserir e assim vai... poderia colocar todos essas ações em um único controller?

Mais uma vez obrigada! desculpa se me prolonguei demais, se caso alguma resposta for respondida ao longo do curso pode falar viu.

solução!

Olá Laís,

Sobre o primeiro ponto: Normalmente validações fazem parte da lógica de negócios. O teu controller recebe os dados, passa para a camada de lógica de negócios, essa camada faz o devido tratamento dos dados recebidos e em seguida retorna com "sucesso" ou "insucesso". E com base nas respostas recebidas, o teu controller saberá qual informações a tua View deve renderizar.

Repositório pode sim ser o Doctrine. Já o service, não necessariamente. Veja o service como um intermediário entre o Controller e a Fonte de dados (que pode ser uma API, um banco de dados - usando Doctrine, etc...). A diferença que eu vejo entre um service e um repositório, posso estar errado, é que o service não sabe como buscar os dados, apenas onde buscar. Enquanto o repositório, além de saber onde buscar, sabe como buscar.

Sim, podes colocar as "ações" relativas ao "Curso" no mesmo controller. O que o Vinícius tem feito é tentar simplificar ao máximo o processo de aprendizagem. Na vida real, dificilmente encontrarás um controller para cada rota do mesmo recurso. É mais comum controllers lidando com rotas relacionadas ao meu recurso. Acredito que quando fizeres o curso de Laravel, este ponto ficará mais claro.

Para terminar, não precisa se desculpar, para isso temos o fórum.

Abs

Valeu WeezHard! consegui entender melhor, ficou mais claro como projetar controllers mais clean! pergunta respondida com sucesso e com qualidade!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software