ASP.NET MVC ViewModel Pattern - PullRequest
       15

ASP.NET MVC ViewModel Pattern

21 голосов
/ 01 сентября 2009

РЕДАКТИРОВАТЬ: Я сделал что-то намного лучше, чтобы заполнял и считывал данные из представления, используя ViewModels , назвал его ValueInjecter . http://valueinjecter.codeplex.com/

используется http://prodinner.codeplex.com - примером приложения ASP.net MVC

вы можете увидеть лучший способ использования ViewModels в Prodinner

Использование ViewModel для хранения логики сопоставления было не очень хорошей идеей, потому что было повторение и нарушение SRP, но теперь с ValueInjecter у меня есть чистые ViewModels и код сухого сопоставления


Это старые вещи, не используйте их:
Я сделал шаблон ViewModel для редактирования материала в asp.net mvc этот шаблон полезен, когда вам нужно создать форму для редактирования сущности, и вам нужно добавить в форму несколько раскрывающихся списков, чтобы пользователь мог выбрать некоторые значения
    public class OrganisationBadViewModel
    {
        //paramterless constructor required, cuz we are gonna get an OrganisationViewModel object from the form in the post save method
        public OrganisationViewModel() : this(new Organisation()) {}
        public OrganisationViewModel(Organisation o)
        {
            Organisation = o;
            Country = new SelectList(LookupFacade.Country.GetAll(), "ID", "Description", CountryKey);  
        }       
        //that's the Type for whom i create the viewmodel
        public Organisation Organisation { get; set; }
...     

    }

Ответы [ 4 ]

11 голосов
/ 09 сентября 2009

Это выглядит очень похоже на рекомендованную практику в книге Wrox Professional ASP.NET MVC , первая глава которой доступна бесплатно по указанному выше URL.

Начиная со страницы 100 у них есть раздел на ViewData и ViewModels .

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

[...]

При использовании шаблона ["ViewModel"] мы создаем строго типизированные классы, которые оптимизированы для наших конкретных сценариев представления и которые предоставляют свойства для динамических значений / содержимого, необходимых нашим шаблонам представления. Наши классы контроллеров могут затем заполнить и передать эти оптимизированные для просмотра классы нашему шаблону представления для использования. Это обеспечивает безопасность типов, проверку во время компиляции и редактирование intellisense в шаблонах представления.

Взято из "Главы 1" Nerd Dinner "из Professional ASP.NET MVC 1.0, написанной Робом Коннери и др., Опубликованной Wrox". Оригинал доступен на http://tinyurl.com/aspnetmvc

9 голосов
/ 08 сентября 2009

Есть пара вещей, которые меня беспокоят.

  1. Терминология. ViewModel в этом случае представляет собой простое представление данных, которое заполняется и затем используется контроллером. View ничего не знает о контроллере, так как инфраструктура ASP.NET MVC отвечает за выбор контроллеров и соответствующие действия. Контроллер обрабатывает взаимодействие с пользователем. Я думаю, что это больше похоже на пассивное представление, чем на ViewModel (я предполагаю, что под ViewModel вы подразумеваете шаблон Model-View-ViewModel).

  2. Подробности. Контроллер, который заполняет данные представления, не должен знать детали того, как представление реализовано. Однако OrganisationViewModel.Country раскрывает ненужные детали (SelectListItem - чистая деталь реализации представления). Таким образом, создание контроллера зависит от просмотра деталей реализации. Я думаю, что это должно быть изменено, чтобы избежать этого. Попробуйте использовать какой-нибудь объект, который будет содержать данные для страны.

Надеюсь, это поможет.

1 голос
/ 25 ноября 2009

Мы начали это делать, но наши контроллеры стали чудовищными (поскольку наши ViewModels не обязательно отображались 1: 1 в нашей базе данных). Чтобы облегчить это, мы создали классы Mapper, которые создают ViewModel и затем отображают обратно данные, привязанные к базе данных. Затем контроллер просто вызывает методы класса Mapper. Кажется, работает хорошо.

1 голос
/ 01 сентября 2009

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

Я не рассматривал каждую строку кода, но одна вещь, которая привлекла мое внимание, - это конструкторы OrganisationViewModel. Я бы переписал это, используя:

public OrganisationViewModel() : this(new Organisation()) { }

public OrganisationViewModel(Organisation o)
{
  Organisation = o;
  InitCollections();
}

Это удаляет некоторый дублирующий код, так как вам не нужно вызывать InitCollections() в обоих конструкторах. Конечно, это лишь незначительная деталь, и она не имеет ничего общего с общей идеей.

...