View model как правильно организовать?

Question

[kid-programmer]

Вопрос в том как правильно организовывать модели в mvc.
1.Вопрос
Например есть страница создания продукта:

public class ProductCreateViewModel
    {
        [Required]
        [Display(Name = "Наименование продукта")]
        public string Name { get; set; }

        //... еще свойства
    }

Страница изменения продукта:

public class ProductEditViewModel
    {
        public int Id { get; set; }
        [Required]
        [Display(Name = "Наименование продукта")]
        public string Name { get; set; }

        //... еще свойства
    }

т.е получается для того чтобы изменить продукт нужны теже свойста что и при создании и одно дополнительное Id. Получается какой-то копипаст из первого во второй. Как правильно делать по феншую?

2.Вопрос
На главной выводится список продуктов которые лежат в определенном разделе

Раздел: Молочные
1.Творог
2.Сыр
3.Ряженка
Раздел:Хлебобулочные
1.Печенье
2.Кекс

public class ProductListViewModel
    {
        List<SectionTdo> Sections {get; set;}
    }

    public class SectionTdo
    {
         public int Id { get; set; }
         public string Name { get; set; }
          List<ProductTdo> Products
    }

    public class ProductTdo
    {
         public int Id { get; set; }
        public string Name { get; set; }
    }

Правильно ли сформирована модель?... Просто немного запутался, получается что для каждого представления своя модель, не смотря на копипаст полей из сущностей домена или как то можно организовать это все подругому.

Answer 1

[Валерий Абакумов]

Всем добрый день! Хм, а чем не угодило наследование? Сделайте базовую модель представления - BaseViewModel, засуньте туда все основные свойства. Если Вам одни свойства нужны для Add, а другие для Edit, так просто одни поместите в AddViewModel, а другие - в EditViewModel. При этом общие свойства типа Id, Name и др. Вам также будут доступны в обеих ViewModel, т.к. и AddViewModel, и EditViewModel будут унаследованы от BaseViewModel.

В защиту такого решения могу сказать следующее:
1. Все общие свойства вынесены отдельно. Они доступны в любой момент. В случае изменения общих свойств их можно редактировать в одном месте.
2. Специальные свойства, нужные только для конкретной ситуации (Add, Edit, Delete, ...), можно вынести в специальную модель представления.

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

По поводу выбора между моделью и представлением: лично я после разработки на WPF с использованием шаблона MVVM использую ViewModel и в MVC. Это позволяет еще больше отделить данные от представления, добавив, как это говорится по-научному, дополнительный уровень абстракции. Так что тут я Вас тоже полностью поддерживаю.

Успехов!

Answer 2

[Railchik]

У вас плохой стиль написания кода. Именуйте переменные как то информативнее, без двусмысленности ProductListViewModel - это модель(Model) или представление(View).
1)

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

да, но вам не нужно клонировать свойства, просто объявите экземпляр класса или унаследуйтесь

public class ProductCreateViewModel    {
        public string Name { get; set; }
        //... еще свойства
    }
public class ProductEditViewModel  {
        public int Id { get; set; } 
        
        public ProductCreateViewModel productCreate

        //... еще свойства

private static void CreateNewProduct(){
  //  здесь обрабатываете состояние
}

    }

2) Наследуйстесь

public class milk{
         public string nameSection { get; set; }
}
public class cheese : milk{
    public string name { get; set; }
}

Просто ООП . Как то так. Может я вас не понял.

Comments

[kid-programmer]

" ProductListViewModel - это модель(Model) или представление(View). "
хм, ViewModel это модель представления

[Алексей Гагарин]

Да вполне нормальный стиль.
Из названия ProductListViewModel предельно ясно, что это ViewModel для действия List.

По теме: "получается что для каждого представления своя модель, не смотря на копипаст полей из сущностей домена" - да, всё верно. Для каждой View вы используете специальную ViewModel, даже тогда, когда она полностью копирует свойства доменного объекта.
Часто методы Create и Edit действительно имеют одинаковую модель. Здесь можно поступить несколькими способами:
1. Сделать так, как вам ответили выше
2. В методе Create использовать ProductEditViewModel. В этом случае ID у вас будет просто 0, всё-равно он нигде не используется. Модель может называться, к примеру CreateEditViewModel
3. Использовать раздельные модели.

Лично я предпочитаю третий вариант. Конечно он ведёт к некому дублированию кода, но я бы назвал это дублированием с натяжкой. Во-первых, вы не копируете никакого поведения, только свойства. Во-вторых этот способ всё-таки избавляет от наследования (я уже дискутировал на тему того, что не стоит использовать наследование только потому, что можно это делать, особенно если речь идёт про пару свойств). В-третьих такое решение гораздо гибче. Как только ваше действия Create и Edit начнут использовать разные свойства моделей, вам, возможно, придётся убирать наследование и всё-таки писать отдельные свойства.

По-поводу второго вопроса - на мой взгляд модель сформирована верно. Ваши продукты сгруппированы по разделам. В цикле вы пробегаете по разделам, где далее пробегаете по продуктам. По-моему, всё правильно.

[kid-programmer]

@Alexey_Gagarin, надо было не в комменте писать а отдельным ответом тогда бы поставил решено. Я тож остановился на варианте 3, спасибо.

[Алексей Гагарин]

@kid-programmer Ну что уж поделать, буду знать ))) Хотя это не главное :)