Bom dia.
Estou modelando um novo projeto e estou com uma dúvida quanto a localização de ViewModels. Tenho estudado bastante e visto vários exemplos e vejo pouca coisa de uma modelagem MVC com DDD e as ViewModels.
Penso que, por exemplo, uma tabela de Cliente pode ter vários e vários campos porém para a inclusão de um novo são necessários apenas alguns (tipo campos UltimaVenda, UltimoAcesso, etc). Da mesma forma para montar uma página com um table mostrando
os últimos clientes cadastrados são necessários apenas alguns campos (Codigo, Nome, CPF e Data de Inclusão por exemplo).
Em todo exemplo de arquitetura que encontro eu vejo que no DDD, nas Interfaces para os repositórios, os métodos retornan direto objeto Cliente, masi ou menos assim:
public Ienumerable<Cliente> RetornarUltimosClientesCadastrados();
O problema que vejo é que se Cliente tem uns 20 campos, eu irei preencher diversas propriedades de Cliente para exibir apenas 4!
Aí entram as ViewsModels, onde eu posso criar um objeto específico para esta view no MVC e daí tenho uma excelente otimização e coesão.
Bom, então na minha forma de pensar eu acho que no ClassLibrary do Domain, onde tem a pasta Entidade, eu poderia ter uma pasta ViewModel também com estas definições e desta forma nas interfaces para os Repositórios eu ter uma IClienteRepository onde o RetornarUltimosClientesCadastrados()
retorna um Ienumerable<UltimosClientesCadastradosViewModel>.
Só que eu não sei se assim vou "ferir" muito a regra do DDD. Vejo que com o tempo esta é a melhor opção pois, hoje com um projeto MVC + EF +Dapper que tenho em diversos clientes eu uso Dapper e EF com Repositórios já retornando ViewModels
e o resultado é muito bom. Incluí o Dapper pois o EF começou a dar dor de cabeça quando alcancei 130 tabelas, sendo algumas com mais de 40 campos.
Obrigado a todos!
Romulo
