ASP.NET MVC, modelo e ViewModel separação de interesses?

Question

Ultimamente, tenho vindo a explorar o que é a melhor maneira de organizar camada de apresentação do aplicativo MVC ASP.NET quando subjacente modelo é complexo. O que veio até agora é a arquitetura MVVM com seus objetos de ViewModel. No entanto, eu não sei o que são as melhores práticas quando este tipo de arquitetura é o caso.

• objetos Does ViewModel pode conter Modelo objetos?
• Se MVVM usado, é aconselhável que os objetos do modelo são usadas em Views?
• Onde validação deve ser implementado, em classes ViewModel ou modelo?
• camada de negócios deve (camada de serviço) saber sobre ViewModel, e que é responsável pelo mapeamento entre ViewModel e modelo?

Answer 1

• Na maioria das vezes, os objetos ModelView são apenas recipientes de modelar objetos quando precisamos enviar vários tipos deles, ou quando precisamos passar par de mais propriedades que só são necessários no Views.
• Se o trabalho do View é para exibir os detalhes de um modelo e não há nada mais para passar para a vista, por que não?
• Depende. Você pode usar suas classes ModelView e modelo apenas para transportar dados entre as camadas. E cuidar de validação via ligantes modelo cutom ou com uma camada de serviço.
• Não há nenhuma razão para que eles não devem saber sobre ModelViews. Mas geralmente você só pegar o Modelo (s) solicitado à camada de serviço do controlador e, em seguida, passá-lo /-los diretamente ou em uma ModelView à View.

BTW, eu não iria considerar ModelViews como uma arquitetura. É mais como "uso um quando você precisa de um". Afinal, não há nenhum ponto em fazer isso para passar dados para a vista:

class SomeModelView {
    public MyModel model { get; set; }
}

Apenas passar o MyModel se isso é suficiente para o fim de fazer o seu trabalho.