Модели общего вида?

Question

Мне интересно, стоит ли пытаться создать представление, использующее модель общего вида?

Мне интересно это, потому что кто-то упомянул, что он ожидал, что ему придется сделать много дублирующего кода, если толькоон начал создавать общий вид и модель общего вида.

Таким образом, в основном представления будут похожи на набор элементов управления.В одном представлении может быть 2 элемента управления (скажем, текстовое поле и переключатель), а в другом - 50 элементов управления.

Все они будут выглядеть одинаково (просто увеличивается в зависимости от количества элементов управления).По сути, он думал о том, что модель представления берет объект (объект домена), смотрит на него и видит 50 полей и отображает правильные типы элементов управления.

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

Мне нравятся шаблоны и они могут делать очень мощные вещи, а в некоторых ситуациях они хороши, но я просто не в восторге от них и стараюсь не использовать.

Я считаю, что в большинстве случаев это может уменьшить количество дублирующегося кода, но иногда это усложняет код.Конечно, это может быть только потому, что я все еще относительно новичок в программировании, и это может быть все еще выше моего уровня квалификации.

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

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

Answer 1

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

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

Идея моделей представления заключается в том, что они должны быть специально привязаны к требованиямконкретное представление, не делая их общими (/ универсальными), как ваши доменные модели.Я предпочитаю дублирование кода в моделях представления, а не повторение какого-либо универсального монстра во всех представлениях и частичках.

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

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

Как говорится, не исключайте их полностью, если вы чувствуете, что есть ситуация, в которой могут быть полезны модели общего представления, не стесняйтесь представить это здесь, объясняя сценарий и показывая весь код так, чтобымы можем это обсудить.

Answer 2

Я не вижу ничего плохого в общих ViewModels.Это хороший способ удалить дублирование и сохранить проверки во время компиляции, в отличие от ViewBag.

Пример:

Представьте, что у вас есть набор классов Model для Product, Category и т. Д. Каждый класс (ProductModel, CategoryModel) имеет связанный шаблон отображения и редактора, который генерирует соответствующий вид.

Теперь вы хотите создать набор страниц для просмотра.и отредактируйте.

Обычно я создаю макет (главную страницу в веб-формах) для отображения общего содержимого (верхний колонтитул, нижний колонтитул, меню и т. д.)

Затем я бы создал индивидуальный, сильнотипизированные представления, которые принимают в качестве модели ProductViewModel, CategoryViewModel и т. д.

Теперь нам нужно определить эти классы модели представления.Каждый класс модели представления должен иметь экземпляр ProductModel, CategoryModel и т. Д. (Которые будут переданы в шаблон).Но для макета часто требуются дополнительные данные (например, выбранное меню, имя пользователя и т. Д.).Мое решение состоит в том, чтобы создать универсальную ViewModel, которая инкапсулирует эти дубликаты данных для макета:

public class EntityViewModel<T>
    where T : EntityModel
{
    public T Entity { get; set; }
    public string UserName { get; set; }
    public string SelectedMenu { get; set; }
}

Затем вы можете легко создать ProductViewModel : EntityViewModel<ProductModel>, который содержит все, что макет нужен для визуализации страницы, и вы можетедобавьте туда любые дополнительные данные для конкретного продукта.

Answer 3

Что касается ViewModels, у меня обычно все мои ViewModel наследуются от BaseViewModel, который предоставляет методы, которые помогают в реализации MVVM.Если вы хотите увидеть пример, просто прокомментируйте ниже.

Answer 4

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