Есть ли необходимость в фабричном классе для создания моделей представления?

Мой коллега предложил использовать фабричный класс для создания объектов модели представления в наших решениях ASP.NET MVC. Идея состоит в том, что это может помочь с дизайном и обслуживаемостью способов представления моделей в наших приложениях.

Я хотел узнать, есть ли у кого-то еще опыт этого. Я провел некоторое исследование и нашел очень мало об этой практике.

В настоящее время мы создаем объекты viewmodel на уровне контроллера, например

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

Так что this.BuildIndexViewModel () отвечает за создание класса viewmodel (очевидно :). Но мы рассматриваем возможность:

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

Это интересная идея, но я не уверен на 100%. Меня интересовали мнения других людей по этому поводу.

design asp.net-mvc

— Джейсон Эванс
источник

Я изо всех сил пытаюсь увидеть выгоду, чтобы быть честным. Вы бы использовали фабрику, чтобы скрыть строительство объектов, но зачем вам в этом случае?

— CodeART

Ваш метод BuildIndexViewModel уже является фабричным методом, который предположительно является частным для контроллера. Единственная причина извлечь это из отдельного фабричного класса - это повторно использовать его в другом контроллере.

— MattDavey

Вы оба разделяете те же мысли, что и я, по этому поводу, поэтому я рад, что я не одинок :) @MattDavey Я могу честно сказать, я очень сомневаюсь, что модели представления будут использоваться с более чем одним контроллером, что делает завод идея излишняя. Я поделюсь этим, когда тема снова поднимется на работе.

— Джейсон Эванс

Лично я предпочел бы, чтобы тип viewmodel был экспертом в процессе конструирования самого себя. Единственный раз, когда экспертиза должна лежать где-то в другом месте, это если для построения требуется знание других областей применения (например, репозиториев), и в этом случае вам может потребоваться, чтобы посредник оставил модель представления немой :)

— MattDavey,

@MattDavey: Можете ли вы обернуть эти два комментария в ответ, который я могу поднять?

— фунтовые

В этом случае я бы сказал, что лучшим руководством будет следовать принципы GRASP . В частности рассмотрим четыре критерия назначения создания объекта:

Как правило, класс B должен отвечать за создание экземпляров класса A, если применяется одно или, предпочтительно, несколько из следующих

Экземпляры B содержат или составно агрегируют экземпляры A
Экземпляры B записывают экземпляры A
Экземпляры B тесно используют экземпляры A
Экземпляры B имеют начальную информацию для экземпляров A и передают ее при создании.

Ваш класс контроллера (B) соответствует элементам # 3 и # 4 этого списка (и # 2, если view-модель отправлена обратно), так что это уже очень разумное место для поведения конструкции viewmodel (A). На мой взгляд, есть только две причины, которые заставили бы меня вынести это конструкционное поведение в класс специалиста.

СУХОЙ - если два или более контроллеров должны совместно использовать поведение конструкции viewmodel, инкапсуляция его в отдельный компонент облегчит повторное использование кода и позволит избежать дублирования.
Если поведение конструкции имеет зависимости от других системных компонентов, таких как репозитории, валидаторы и т. Д., И вы не хотите вводить эту связь с самим контроллером (в терминах GRASP, чистая выдумка).

Оглядываясь назад на эти 4 критерия создания объектов в GRASP, я бы извлек поведение только в отдельную фабрику, если бы это принесло мне дополнительную отметку в этом списке. Иначе не было бы никакой ценности в этом.

Надеюсь, это поможет!

— MattDavey
источник