Padrão de repositório com camada de serviço - muita separação?

Eu tenho um site MVC que usa o padrão de repositório. Eu não sinto que estou usando o estilo MVC o suficiente, então estou me preparando para re-arquitetar parte dele. Mas também estou querendo fazê-lo, se o front-end mudar, será mais fácil trocar.

Aqui está o que eu tenho atualmente

Modelos - alguns dos meus modelos contêm minhas entidades / classes diretamente. (O modelo de login contém a classe Customer, que é uma correlação direta com a tabela Customer / repository class) Views - algumas das minhas visualizações contêm consultas repo - ou seja,

_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);

Controladores - Não é grande coisa aqui, controladores chamando algumas consultas de repo, e alguns deles também usam alguns serviços para chamar os repos -

_customerService.GetAllCustomers()

que chama

_customerRepo.Query().All();

Aqui estão os meus pensamentos:

1) Os modelos devem conter APENAS os dados necessários para serem apresentados na exibição. Mesmo que todas as propriedades da tabela / objeto Customer sejam apresentadas na exibição, elas devem ser reescritas em seu próprio modelo / classe para que a exibição não saiba nada sobre a arquitetura do banco de dados ou os objetos de back-end

2) As vistas devem acessar apenas objetos de modelo

3) (E é aqui que estou lutando em qual caminho seguir)

a) Controladores (ou em algum lugar do lado do MVC, devem ser códigos que convertam os dados do objeto retornados dos repositórios / serviços e os convertem para os modelos. Estou assumindo que eu poderia colocar esse código em um construtor de modelos. Mas eu ' notei que o DI espera um construtor vazio padrão, caso haja erros de validação

b) Os controladores chamam interfaces de repo em métodos bem nomeados para recuperar dados (ou seja, _customerRepo.GetAllCustomers ()

c) Os controladores acessam SOMENTE uma camada de serviço. A camada de serviço é a única coisa que interage com a camada de repo.

Estou tentando extrair demais as camadas de modelo, controlador, serviço e repo? A camada de serviços é sobrecarga demais, pois tudo pode ser feito pelos repositórios?

Qual é a abordagem recomendada para converter os objetos / entidades de negócios nos modelos?

Sim, a camada de serviço é uma sobrecarga se você não tiver nenhuma lógica comercial lá. A arquitetura em camadas parece uma sobrecarga quando uma camada (no seu caso, serviço) não está fazendo muito. Mas uma arquitetura em camadas fornece seu acoplamento flexível, o que geralmente é bom para adaptar os requisitos no futuro.

Se você pode garantir que nunca precisará fazer nada na camada de serviço, exceto a cópia de dados do repositório para o modelo, poderá remover a camada de serviço em seu design. No entanto, se o seu aplicativo for básico, você não precisará se preocupar em adicionar outra camada por desempenho ou por outro motivo.

Pessoalmente, manterei a camada de serviço e (depende da tecnologia) implementarei uma camada genérica de DAO / Repository.

Depende dos seus repositórios concretos, mas de um modo geral, eu adicionaria uma camada de serviço sobre os repositórios.

Dependendo da implementação do seu repositório, eles podem ser específicos ao seu armazenamento de persistência. Isso facilita o teste e leva a uma arquitetura hexagonal, em vez de uma arquitetura clássica em camadas (que considero um benefício), consulte https://blog.8thlight.com/uncle-bob/2012/08/13/the- clean-architecture.html .

Para esclarecer um pouco o que é um controlador: o MVC data de quando tínhamos mainframes e aplicativos de tela de texto. O Modelo era o dado no mainframe, o View era a tela do terminal e o Controller era o teclado (pressione # para manipular o modelo).

As coisas mudaram e hoje em dia usamos o mouse e os botões (para controlar o aplicativo) são exibidos na tela.