Existe uma necessidade de uma classe de fábrica para criar modelos de exibição?

Um colega meu sugeriu o uso de uma classe de fábrica para criar objetos viewmodel em nossas soluções ASP.NET MVC. A ideia é que ele pode ajudar no design e na manutenção da maneira como os modelos de exibição são criados em nossos aplicativos.

Eu queria descobrir se mais alguém tem experiência nisso. Eu fiz algumas pesquisas e descobri muito pouco sobre essa prática.

Atualmente, criamos objetos viewmodel no nível do controlador, por exemplo

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

Portanto, this.BuildIndexViewModel () é responsável por criar a classe viewmodel (obviamente :). Mas estamos analisando a possibilidade de:

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

Esta é uma ideia interessante, mas não estou 100% convencido. Eu estava interessado na opinião de outras pessoas sobre isso.

design asp.net-mvc

— Jason Evans
fonte

Eu luto para ver o benefício de ser honesto. Você usaria uma fábrica para ocultar a construção de objetos, mas por que você usaria neste caso?

— CodeART

Seu método BuildIndexViewModel já é um método de fábrica, que é privado para o controlador, presumivelmente. O único motivo para extrair isso para uma classe de fábrica distinta seria reutilizá-lo em outro controlador.

— precisa saber é o seguinte

Vocês compartilham os mesmos pensamentos que eu sobre isso, então estou feliz por não estar sozinha :) @MattDavey Posso dizer honestamente que duvido muito que os modelos de visualização sejam usados com mais de um controlador, o que torna a fábrica ideia redundante. Vou compartilhar isso quando o tópico surgir novamente no trabalho.

— 23412 Jason Evans

Pessoalmente, eu preferiria que o tipo viewmodel fosse o especialista no processo de construção de si mesmo. A única vez que a perícia devem estava em outro lugar é se a construção requer o conhecimento de outras áreas de aplicação (por exemplo, repositórios), caso em que você pode querer um intermediário para manter o viewmodel mudo :)

— MattDavey

@MattDavey: Você pode colocar esses dois comentários em uma resposta que eu possa votar?

— Pd #

Nesse caso, eu diria que a melhor orientação a seguir seriam os princípios GRASP . Em particular, observe os quatro critérios para atribuir a criação de objetos:

Em geral, uma classe B deve ser responsável por criar instâncias da classe A se um, ou preferencialmente mais, dos seguintes itens se aplicar

As instâncias de B contêm ou agregam composições de instâncias de A
Instâncias de instâncias de registro B de A
As instâncias de B usam de perto as instâncias de A
As instâncias de B têm as informações de inicialização das instâncias de A e as transmitem na criação.

Sua classe de controlador (B) corresponde aos itens # 3 e # 4 dessa lista (e # 2 se o viewmodel for POSTADO de volta), portanto, já é um local sensato para o comportamento da construção do viewmodel (A). A meu ver, haveria apenas duas razões que me obrigariam a extrair esse comportamento de construção em uma classe especializada.

SECO - Se dois ou mais controladores precisarem compartilhar o comportamento de construção do modelo de exibição, encapsulá-lo em um componente distinto facilitaria a reutilização do código e evitaria a duplicação.
Se o comportamento de construção tiver dependências de outros componentes do sistema, como repositórios, validadores, etc., e você não desejar introduzir esse acoplamento no próprio controlador (nos termos do GRASP, uma fabricação pura).

Olhando para trás para esses quatro critérios de criação de objetos no GRASP, eu extrairia o comportamento apenas para uma fábrica separada se me desse um tique adicional nessa lista. Caso contrário, não haveria valor em fazê-lo.

Espero que ajude!

— MattDavey
fonte