¿Existe la necesidad de una clase de fábrica para crear modelos de vista?

Un colega mío sugirió usar una clase de fábrica para crear objetos de modelo de vista en nuestras soluciones ASP.NET MVC. La idea es que puede ayudar con el diseño y la capacidad de mantenimiento de la forma en que se construyen los modelos de vista en nuestras aplicaciones.

Quería saber si alguien más tiene experiencia en esto. Investigué un poco y encontré muy poco en esta práctica.

Actualmente creamos objetos de modelo de vista a nivel de controlador, por ejemplo

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

Entonces this.BuildIndexViewModel () es responsable de crear la clase viewmodel (obviamente :). Pero estamos estudiando la posibilidad de:

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

Esta es una idea interesante, pero no estoy 100% convencido. Estaba interesado en las opiniones de otras personas sobre esto.

design asp.net-mvc

— Jason Evans
fuente

Me cuesta ver el beneficio para ser honesto. Usarías una fábrica para ocultar la construcción de objetos, pero ¿por qué lo harías en este caso?

— CodeART

Su método BuildIndexViewModel ya es un método de fábrica, presumiblemente privado para el controlador. La única razón para extraer eso a una clase de fábrica distinta sería reutilizarlo en otro controlador.

— MattDavey

Ambos comparten los mismos pensamientos que yo sobre esto, así que me alegro de no estar solo :) @MattDavey Puedo decir honestamente que dudo mucho que los modelos de vista se utilicen con más de un controlador, lo que hace que la fábrica idea redundante Compartiré esto cuando el tema vuelva a aparecer en el trabajo.

— Jason Evans el

Personalmente, preferiría que el tipo de modelo de vista sea el experto en el proceso de construcción. El único momento en que la experiencia debería estar en otro lado es si la construcción requiere el conocimiento de otras áreas de aplicación (por ejemplo, repositorios), en cuyo caso es posible que desee un intermediario para mantener el modelo de vista tonto :)

— MattDavey

@MattDavey: ¿Puedes incluir esos dos comentarios en una respuesta que pueda votar?

— pdr

En este caso, diría que la mejor guía a seguir serían los principios GRASP . En particular, observe los cuatro criterios para asignar la creación de objetos:

En general, una clase B debería ser responsable de crear instancias de clase A si se aplica una, o preferiblemente más, de las siguientes

Las instancias de B contienen o agregan compositivamente instancias de A
Instancias de instancias de registro B de A
Las instancias de B usan de cerca las instancias de A
Las instancias de B tienen la información de inicialización para las instancias de A y la pasan en la creación.

Su clase de controlador (B) coincide con los elementos n. ° 3 y n. ° 4 de esa lista (y n. ° 2 si el modelo de vista se PUBLICA), por lo que ya es un lugar muy sensible para el comportamiento de construcción del modelo de vista (A). Según lo veo, solo habría dos razones que me obligarían a extraer ese comportamiento de construcción en una clase especializada.

SECO : si dos o más controladores necesitan compartir el comportamiento de construcción del modelo de vista, encapsularlo en un componente distinto facilitaría la reutilización del código y evitaría la duplicación.
Si el comportamiento de construcción depende de otros componentes del sistema, como repositorios, validadores, etc., y no desea introducir este acoplamiento en el controlador (en términos GRASP, una fabricación pura).

Mirando hacia atrás a esos 4 criterios de creación de objetos en GRASP, solo extraería el comportamiento a una fábrica separada si me ganara una marca adicional en esa lista. De lo contrario, no tendría ningún valor hacerlo.

¡Espero que ayude!

— MattDavey
fuente