Увлажнение ViewModels в ASP.NET MVC

Question

У меня есть страница, которая состоит из множества пользовательских элементов управления. Модель представления для этой страницы довольно сложна.

public class ComplexViewModel
{
    public ObjectA ObjectAProperty { get; set; }
    public List<Things> ListOfThings { get; set; }
    public List<ThingCategories> ListOfThingCategories { get; set; }
    public List<ThingTypes> ListOfThingTypes { get; set; }
    public List<ThingOptions> ListOfThingOptions { get; set; }
    public int ChosenThingCategoryId { get; set; }
    public int ChosenThingTypeId { get; set; }
    public int ChosenThingOptionId { get; set; }
    public OtherObject ObjectData { get; set; }
}

На этой странице также есть PostModel, который содержит информацию для фильтрации, сортировки и т. Д.

    public class SimplePostModel
{
    public int ChosenThingCategoryId { get; set; }
    public int ChosenThingTypeId { get; set; }
    public int ChosenThingOptionId { get; set; }
    public int ChosenThingFilterTypeId { get; set; }
    public int ChosenThingSortTypeId { get; set; }
    public int ChosenThingOtherId { get; set; }
    public int ChosenThingMoreId { get; set; }
    public int ChosenThingOMGId { get; set; }
}

Проверяется простая модель PostModel, а затем контроллер открывает более 3 репозиториев, делая несколько вызовов в каждый, и строит модель представления. По меньшей мере, мое действие контроллера стало довольно большим.

Это, безусловно, самая сложная страница, над которой я работал, и мне трудно решить, как ее упростить.

Моей первой мыслью было создание фабрики моделей представлений, которая после проверки привязки вызывала бы репозитории и возвращала ViewModel.

Затем я подумал о создании пользовательского связывателя модели, который будет проверять PostModel, а затем увлажнять ViewModel за один шаг.

Итак, мой вопрос, как вы увлажняете модель сложного вида?

И пока я писал это, у меня была идея использовать Html.RenderAction и создать модель для каждого из пользовательских элементов управления, которые составляют этого зверя страницы.

Обновление:

Репозитории совершают вызовы в сервисы WCF, приложение является частью большой арки SOA.

Answer 1

Несколько общих советов. Данные можно разделить на несколько категорий: системная область, область сеанса, область запроса.

Данные области действия системы - это данные, которые должны быть представлены пользователю, но одинаковы для каждого пользователя. Примером приложения блога может служить облако тегов или список категорий. Я бы сказал, что эти данные не должны проходить через контроллер или действие, потому что они не имеют никакого отношения к взаимодействию с пользователем. Само представление может вызывать HtmlHelper (или LayoutDataHelper), который знает, как получить (и предпочтительно кэшировать) эти данные.

Данные области действия сеанса могут обрабатываться с помощью ActionFilters, которые заполняют поля в ViewData.Model. Это не имеет прямого отношения к параметрам действия. Например, имя пользователя. Я предпочитаю атрибут вида

public class SessionDataFilter : ActionFilter 
{
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if (filterContext.Result is ViewResult)
        {
            var view = filterContext.Result as ViewResult;

            // hydrate session data on view.ViewData.Model
        }
    }
}

Все остальное, что является областью действия запроса / конкретной, должно быть заполнено в действии. Тем не менее, это не значит, что для этого нужен один массивный метод действий. Я бы посмотрел, как составлены ваши ViewModels. Как вы предложили, если у вас есть элементы управления, которые необходимо заполнить, вполне вероятно, что информация в ViewModel может быть сгруппирована в связанные наборы. Так что у вас может быть ViewModel, которая просто составляет другие меньшие модели представления («модели частичного представления»). Затем я разложил бы логику, чтобы заполнить каждую модель частичного представления (и любую другую сложную логику) каждой в свой собственный повторно используемый и изолированный метод.

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

Удачи.