Це гарна ідея додати ViewModel точно так само, як і Model

У моєму розчині є такі шари:

1. Додаток.Домен
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" продовжувати використовувати старі інтерфейси? Ви коли-небудь розкриєте терміни чи операції в інтерфейсі, які не є частиною "основних правил бізнесу"? І навпаки?

Такі питання на увазі, якщо "функція" вашого зору полягає в чіткому розкритті основної моделі домену, так, це здається, що це порушує правило DRY.

_{Також майте на увазі, висловлюючи думку про те, що більш природні зміни зі змінами моделі також можуть бути здійснені на деяких мовах з атрибутами членів та відображенням. (Або з меншою повторенням через інші подвиги кмітливості ... Але "розумність" часто не може виправдати повторення, яке вона вас щадить.)}

Я мав би модель перегляду, яка містила лише одне властивість, екземпляр Foo. Таким чином, ви не порушуєте DRY згідно з будь-яким його визначенням, якщо Foo змінюється, ваша модель перегляду автоматично бачить зміни, і ви залишаєте себе вільним від прямої прив’язки моделі перегляду до моделі.

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

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

Не впевнений, чи я це чітко пояснив. Якщо ні, то дайте мені знати, і я спробую переробити це, коли прокинусь!

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