Чи потрібен заводський клас для створення моделей перегляду?

Моя колега запропонувала використовувати заводський клас для створення об’єктів viewmodel у наших рішеннях ASP.NET MVC. Ідея полягає в тому, що це може допомогти в дизайні та ремонтопридатності способу побудови моделей перегляду в наших додатках.

Я хотів з’ясувати, чи має хтось ще досвід цього. Я провів деякі дослідження і знайшов дуже мало цієї практики.

В даний час ми створюємо об'єкти viewmodel на рівні контролера, наприклад

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

Отже, цей.BuildIndexViewModel () відповідає за створення класу viewmodel (очевидно :). Але ми розглядаємо можливість:

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

Це цікава ідея, але я не на 100% переконаний. Мене цікавили думки інших людей з цього приводу.

design asp.net-mvc

— Джейсон Еванс
джерело

Я намагаюся бачити користь, щоб бути чесним. Ви б використовували фабрику, щоб приховати будівництво об'єктів, але навіщо вам у такому випадку?

— CodeART

Ваш метод BuildIndexViewModel - це вже заводський метод, який, мабуть, є приватним для контролера. Єдиною причиною вилучення цього з різних заводських класів було б повторне використання його в іншому контролері.

— MattDavey

Ви обоє поділяєте ті ж думки, що й я, з цього приводу, тому я радий, що я не один :) @MattDavey Я, чесно можу сказати, дуже сумніваюсь у тому, що viewmodels будуть використовуватися з більш ніж одним контролером, що робить завод ідея зайва. Я поділюсь цим, коли тема знову з’явиться на роботі.

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

Особисто я вважаю за краще, щоб тип viewmodel був експертом у процесі побудови самого себе. Єдиний час, коли експертиза повинна лежати в іншому місці, це якщо конструкція вимагає знань в інших областях додатків (наприклад, сховищах); у такому випадку ви можете хотіти посередника, щоб тримати

— вигляд моделі

@MattDavey: Чи можете ви зафіксувати ці два коментарі у відповідь, яку я можу підтримати?

— пдр

У цьому випадку я б сказав, що найкращими рекомендаціями слід керуватись принципами GRASP . Зокрема, подивіться на чотири критерії призначення об'єкта створення:

Загалом клас B повинен відповідати за створення екземплярів класу A, якщо застосовується один, або бажано більше, з наступного

Екземпляри B містять або композиційно агрегують екземпляри A
Примірники B записують екземпляри A
Екземпляри B тісно використовують екземпляри A
Екземпляри B мають інформацію про ініціалізацію для екземплярів A і передають її на створення.

Ваш клас контролера (B) відповідає пунктам №3 та №4 цього списку (і №2, якщо модель перегляду повернуто назад), тож це вже дуже розумне місце для поведінки конструкції viewmodel (A). Як я бачу, це було б лише з двох причин, які змусили б мене віднести цю конструкційну поведінку до класу спеціалістів.

СУХО - Якщо двом або більше контролерам потрібно поділити поведінку конструкції модельного виду, інкапсуляція його в окремий компонент полегшить повторне використання коду та уникне дублювання.
Якщо поведінка конструкції залежить від інших системних компонентів, таких як сховища, валідатори тощо, і ви не хочете вводити цю сполуку до самого контролера (з точки зору GRASP, чисто виробництво).

Озираючись на ці 4 критерії створення об’єктів у GRASP, я виведу поведінку на окрему фабрику, лише якщо вона отримає мені додатковий галочок у цьому списку. Інакше не було б ніякої цінності при цьому.

Сподіваюся, що це допомагає!

— MattDavey
джерело