Это хорошая идея, чтобы добавить ViewModel точно так же, как модель

У меня есть следующие слои в моем решении:

1. App.Domain
2. App.Service
3. App.Core (возможно, вы называете это App.DataLayer)
4. App.Web

Шаблон проектирования программного обеспечения не мой вопрос, у меня есть следующая модель в Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Я хочу использовать эту модель в представлении (например, на домашней странице) И я хочу использовать Id, Name & Value, поэтому, если я хочу создать ViewModel, я добавлю следующее:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Так это хорошая идея? или просто использовать Fooвместо FooViewModel?

На первый взгляд это может выглядеть как нарушение правила DRY, но я бы сказал, что «похожий и даже идентичный код» не обязательно «повторяется», если он делает что-то другое или может измениться независимо. А в случае моделей представлений код определяет то, что видит «клиент», а не обязательно объекты и операции, о которых говорит бизнес. Таким образом, вы часто показываете клиенту или интерфейсу модели, которые являются «случайно идентичными». Вы можете изменять бизнес-правила и условия или терминологию конечного пользователя независимо друг от друга.

Итак, я бы перевернул вопрос обратно на вас. Если домен изменяется, допустимо ли для клиентов «версии 1» продолжать использовать старые интерфейсы? Будете ли вы когда-нибудь раскрывать термины или операции в интерфейсе, которые не являются частью "основных бизнес-правил"? И наоборот?

Подобные вопросы в виду, если «функция» вашего взгляда состоит в том, чтобы строго раскрыть модель предметной области, да, похоже, что это нарушает правило СУХОЙ.

_{Также имейте в виду, что представление некоторых более естественных изменений с изменениями модели также может быть достигнуто в некоторых языках с атрибутами и отражением элемента. (Или с меньшим количеством повторений через другие умные умения ... Но «умный ум» часто не оправдывает повторение, которое вас щадит.)}

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

Если завтра необходимо, чтобы представление показывало что-то еще, а также Foo, вы можете просто добавить новое свойство, и намерение модели представления все равно будет ясным, оно содержит Foo и что-то еще, у вас не будет смесь свойств от Foo с несвязанными другими свойствами.

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

Не уверен, что я объяснил это ясно. Если нет, дайте мне знать, и я постараюсь перефразировать его, когда я не сплю!

Я бы сказал, что использование FooViewModelтаким образом нарушает принцип DRY. Когда вам нужно внести изменения, Fooвы также должны внести изменения в FooViewModel. Я думаю, что вы бы лучше служили, просто используя Fooв качестве модели для вашего взгляда. Я хотел бы рассмотреть модель представления, если вам нужно отобразить вещи из Foo и что-то другое. Например, скажем, вам нужно визуализировать некоторую информацию из, Fooа также из Bar.