Não era melhor implementar uma camada de serviço entre as Actions e o Repository?

Perfeito Arthur, numa aplicação real nós teriamos a camada de service com a regra de negócio fazendo a ponte entre controller e repository.

Olá Arthur, tudo bem com você?

Acho que é isso mesmo. Talvez pela aplicação ser apenas um CRUD simples e não conter lógica de negócio relacionada às queries que fazemos no repository, o instrutor decidiu que não haveria a necessidade de implementar uma camada de serviços.

Enfim, desde que respeitemos o princípio da responsabilidade única do SOLID, acredito não haver nenhum problema. Só é incomum encontrarmos situações simples como essa onde não precisamos aplicar uma lógica de negócio básica...

Faz sentido? Qualquer coisa estou à disposição!

Grande abraço e bons estudos!!

Thiago, faz sentido sim! Mas posso tirar algo a limpo?

Como eu nunca trabalhei em um projeto real, meu conceito sobre regras de negócio (que são estudos mais voltados para Engenharia de Software, etc) ainda são meio rasos.

Após procurar no Google, e relembrar um pouco das coisas que eu já tinha visto, uma regra de negócio, em pouquíssimas palavras (e uma de varias definições) seria: Tratar, modificar as informações do sistema de acordo com alguma (ou mais) condição. As vezes, antes de persistir uma informação, um objeto, eu preciso tratá-la antes. Portanto, o lugar certo para se fazer isso seria numa camada de Serviço, e não na Action em si ou no Repository. Este é o caminho?

Opa Arthur, é isso mesmo!

A sua definição está correta também, todo sistema possui funcionalidades e são as regras de negócio que irão definir como essas funcionalidades serão implementadas e como elas farão o processamento das informações no sistema. Pior que uma funcionalidade não implementada, só um uma regra de negócio mal especificada! (e para achar o bug depois!?)

Enfim, esse é o caminho certo. Se estivermos trabalhando em um sistema grande e as regras de negócio estiverem todas espalhadas pelas camadas de controle e persistência, pode acreditar que qualquer vírgula que nós mudarmos na lógica de negócio por trás da aplicação vai causar uma bela dor de cabeça!