View model, domain model, qual model?

Um dos grandes problemas conceituais ao trabalhar com ASP.NET MVC está na letra “M” de MVC.

A criação de um projeto no Visual Studio do tipo ASP.NET MVC não induz a boas práticas. Temos apenas uma pasta “Models” criada dentro do próprio projeto. Nada de uma sugestão de o que seria o tal “M”.

De fato, o termo “Model” é bastante abrangente e, dependendo do contexto, pode ter um significado diferente. (Outro exemplo é o termo “Serviço”.)

Uma boa prática comumente adotada – por mim, inclusive – é o uso de “view models” na camada de apresentação e um “domain model” para abrigar as regras de negócio da aplicação, na camada de domínio.

Vamos ver do que se trata cada um desses 2 conceitos:

DOMAIN MODEL

– Modelo de objetos – dados e comportamento – que representa o domínio do negócio.

– Forma uma camada isolada das demais camadas da aplicação.  Não é criado levando-se em consideração qual o tipo de interface será utilizado (web, mobile, windows, …), por exemplo.

– Como diz Eric Evans, é o “coração do software”.

VIEW MODEL

– Faz parte da camada de apresentação. Eu particularmente renomeio a pasta “Models” para “ViewModels”.

– Responsável por exibir/coletar dados do usuário.

– Pode conter regras de validação – como de campos obrigatórios – e regras para exibição de informações – como habilitar/desabilitar determinado botão.

– Para cada tipo “view model”, há exatamente uma view fortemente tipada.

SEPARAÇÃO DE RESPONSABILIDADES

No início do texto, mencionei o uso desses conceitos como uma boa prática. Mas afinal, por que seria uma boa prática?

Revendo acima as características de cada conceito, percebemos que suas responsabilidades são totalmente diferentes. Enquanto todo o conhecimento do negócio está no domain model, os view models lidam apenas com preocupações de apresentação.

Essa separação de responsabilidades deixa a aplicação mais organizada e mais fácil de ser compreendida pelos desenvolvedores. Além disso, mantendo responsabilidades de apresentação longe do domínio, podemos utilizar o mesmo domain model para outros tipos de apresentação.

DUPLICAÇÃO DE CÓDIGO?

Você pode estar se perguntando: mas eu não estou duplicando código? Em alguns casos, como em cadastros muito básicos, pode ser que um objeto de domínio seja bem parecido ao view model usado para o cadastro.

Mas volto a repetir, são responsabilidades diferentes! O objeto de domínio terá, além de dados, comportamento específico ao negócio e, portanto, neste caso, não considero como uma duplicação maligna.

MAPEAR DADOS DE UM MODEL PARA OUTRO

“Ok. Mesmo assim, tenho um overhead ao ter que mapear informações de um ou mais objetos do domínio para um view model.” Sim. É o preço a ser pago por essa decisão de arquitetura.

Pode ser, de fato, um trabalho muito chato ficar copiando dados de um objeto de domínio para um view model “na mão” (propriedade por propriedade).

Para facilitar, é comum utilizarmos algum framework para essa cópia de dados, como o AutoMapper.

CONCLUSÃO

Vimos, neste post, a diferença entre view model e domain model e quais os ganhos ao se trabalhar com estes dois conceitos em uma aplicação ASP.NET MVC.